"instance_eval" (eg, sent to a class object)

ruby-talk
1

I've poked around, but I don't get instance_eval at all.

I do know what it means to evaluate code in the context of a *class*
object. Ie, I know what *this* does:

    class Foo
      # We're now in the context of the object Foo.
      C = 1
      class Bar
  def bar ; "bar" ; end
      end
      def foo ; "foo" ; end
    end
    p Foo::C -> 1
    p Foo::Bar.new.bar -> "bar"
    p Foo.new.foo -> "foo"

Now let's try this again with "instance_eval":

    class Foo
    end
    Foo.instance_eval do
      # We're now supposedly in the context of the object Foo.
      C = 1
      class Bar
  def bar ; "bar" ; end
      end
      def foo ; "foo" ; end
    end
    p Foo::C
    p Foo::Bar.new.bar
    p Foo.new.foo

Nothing works as I expected. The result is:

tmp.rb:26: warning: toplevel constant C referenced by Foo::C
1
tmp.rb:27: warning: toplevel constant Bar referenced by Foo::Bar
"bar"
tmp.rb:28: undefined method `foo' for #<Foo:0x401c25b0> (NoMethodError)

Evidentally, C and Bar scoped lexically, rather than being in the
context of Foo. And the foo definition ended up in the context of
"class <<Foo ... end".

So, hat in hand, I ask for a description of "instance_eval".

···

--
Posted via http://www.ruby-forum.com/.

2

Hi --

I've poked around, but I don't get instance_eval at all.

I do know what it means to evaluate code in the context of a *class*
object. Ie, I know what *this* does:

   class Foo
     # We're now in the context of the object Foo.
     C = 1
     class Bar
def bar ; "bar" ; end
     end
     def foo ; "foo" ; end
   end
   p Foo::C -> 1
   p Foo::Bar.new.bar -> "bar"
   p Foo.new.foo -> "foo"

Now let's try this again with "instance_eval":

   class Foo
   end
   Foo.instance_eval do
     # We're now supposedly in the context of the object Foo.
     C = 1
     class Bar
def bar ; "bar" ; end
     end
     def foo ; "foo" ; end
   end
   p Foo::C
   p Foo::Bar.new.bar
   p Foo.new.foo

Nothing works as I expected. The result is:

tmp.rb:26: warning: toplevel constant C referenced by Foo::C
1
tmp.rb:27: warning: toplevel constant Bar referenced by Foo::Bar
"bar"
tmp.rb:28: undefined method `foo' for #<Foo:0x401c25b0> (NoMethodError)

Evidentally, C and Bar scoped lexically, rather than being in the
context of Foo. And the foo definition ended up in the context of
"class <<Foo ... end".

So, hat in hand, I ask for a description of "instance_eval".

It changes 'self' to the receiver, for the duration of the block.
That's pretty much all it does. So here:

class A
end

"hello".instance_eval { class B; end }

class B doesn't care that some string has become self; it still
considers itself a top-level class definition.

David

···

On Sat, 17 Nov 2007, Greg Weeks wrote:

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing With Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!

3

It only affects the execution context by binding self to the instance,
NOT the lexical context.

···

On Nov 16, 2007 4:06 PM, Greg Weeks <greg.weeks@arm.com> wrote:

I've poked around, but I don't get instance_eval at all.

I do know what it means to evaluate code in the context of a *class*
object. Ie, I know what *this* does:

    class Foo
      # We're now in the context of the object Foo.
      C = 1
      class Bar
  def bar ; "bar" ; end
      end
      def foo ; "foo" ; end
    end
    p Foo::C -> 1
    p Foo::Bar.new.bar -> "bar"
    p Foo.new.foo -> "foo"

Now let's try this again with "instance_eval":

    class Foo
    end
    Foo.instance_eval do
      # We're now supposedly in the context of the object Foo.
      C = 1
      class Bar
  def bar ; "bar" ; end
      end
      def foo ; "foo" ; end
    end
    p Foo::C
    p Foo::Bar.new.bar
    p Foo.new.foo

Nothing works as I expected. The result is:

tmp.rb:26: warning: toplevel constant C referenced by Foo::C
1
tmp.rb:27: warning: toplevel constant Bar referenced by Foo::Bar
"bar"
tmp.rb:28: undefined method `foo' for #<Foo:0x401c25b0> (NoMethodError)

Evidentally, C and Bar scoped lexically, rather than being in the
context of Foo. And the foo definition ended up in the context of
"class <<Foo ... end".

So, hat in hand, I ask for a description of "instance_eval".

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

4

It changes 'self' to the receiver, for the duration of the block.

It only affects the execution context by binding self to the instance

And the value of self affects:

  - explicit uses of "self"
  - naked message-sends
  - instance and class variable access

Anything else?

Hmmm. This is still a mystery:

    class Foo
    end
    Foo.instance_eval do
      def foo ; "foo" ; end
    end
    p Foo.singleton_methods -> ["foo"]

The "def" should have gone into the top-level environment, but it went
into <<Foo instead. So my hat is still out. (But I'm a lot better off
than I was.)

···

--
Posted via http://www.ruby-forum.com/\.

5

This is related to another thread about constant name resolution (subject "constant name resolution and module_eval").

Why then *_eval (BLOCK|STRING) behave different?

   C = "Object"

   class String
     C = "String"
   end

   a = ''
   a.instance_eval do
     def c_in_block; C; end
   end

   a.instance_eval <<EOS
     def c_in_string; C; end
   EOS

   puts a.c_in_block # -> Object
   puts a.c_in_string # -> String

Looks like there's a "current" module for constant name resolution, and another "current" module for method definition etc.

-- fxn

···

On Nov 16, 2007, at 11:00 PM, Rick DeNatale wrote:

It only affects the execution context by binding self to the instance,
NOT the lexical context.

6

Consider

# At the top level self is a specific top-level object

def foo
   # This method will be a singleton method of the top-level object
   # It's installed in the method-hash of the singleton-class of the
top level object.
end

# when methods are required in reponse to a send, a search is
instituted starting with the receivers klass (i.e. it's true class
which may
# be a singleton class which is put on the search chain ahead of the
objects 'birth' class.
# Classes, including singleton classes, have a method hash which maps
method names to methods.
# For purposes of this post, I'm going to say that classes contain the
methods of their instances via this method hash.

Foo.instance_eval do
      # self is now the class object named Foo
      def foo2
         # This method will be a singleton method of Foo
         # it gets installed in the method-hash of the singleton-class of Foo
      end
end

Now the fact that foo2 is a singleton method is a side-effect of
sorts. It's really a class method of Foo.

It get's reported as a singleton class because it's 'contained' in a
singleton class. This is true of normal class methods for example:

Array.singleton_methods => [""]
Array.methods(false) => [""]

Now all this begged a question in my mind. That is, what's the
difference between instance_eval and class_eval (with its alias
module_eval). A little digging in the 1.8.6 MRI code reveals that
both use the same underlying code, but the inner c function
specific_eval (in eval.c) takes both a klass and a self argument.

Both rb_object_instance_eval (the code behind Kernel#instance_eval)
and rb_mod_module_eval (the code behind both Module#module_eval and
Module#class_eval) set the self argument to the receiver.

rb_obj_instance_eval sets the klass argument to the singleton_class of
the receiver (creating it if it doesn't already exist), unless the
receiver is an immediate object (a Fixnum, or nil, true, or false) in
which case it sets klass to nil.

rb_mod_module_eval sets the klass argument to the receiver which must
be a module or a class. It's the klass argument of specific_eval
which ultimately determines the destination of a method defined by
def;end in the block.

···

On Nov 16, 2007 5:59 PM, Greg Weeks <greg.weeks@arm.com> wrote:

> It changes 'self' to the receiver, for the duration of the block.

> It only affects the execution context by binding self to the instance

And the value of self affects:

  - explicit uses of "self"
  - naked message-sends
  - instance and class variable access

Anything else?

Hmmm. This is still a mystery:

    class Foo
    end
    Foo.instance_eval do
      def foo ; "foo" ; end
    end
    p Foo.singleton_methods -> ["foo"]

The "def" should have gone into the top-level environment, but it went
into <<Foo instead. So my hat is still out. (But I'm a lot better off
than I was.)

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

7

Xavier Noria wrote:

   C = "Object"

   class String
     C = "String"
   end

   a = ''
   a.instance_eval do
     def c_in_block; C; end
   end

   a.instance_eval <<EOS
     def c_in_string; C; end
   EOS

   puts a.c_in_block # -> Object
   puts a.c_in_string # -> String

The more that I think about scoping in the context of

    closures define_method instance_eval module_eval eval

the more confused I get. Alas, I've never seen a formal description of
the Ruby execution model. There seems to be a current self and a
current klass, but I don't know exactly how they are set and used.

I'll just say here that your fine example can be simplified a little:

    a.instance_eval { C } -> "Object"
    a.instance_eval "C" -> "String"

···

--
Posted via http://www.ruby-forum.com/\.

8

Rick Denatale wrote:

def foo
   # This method will be a singleton method of the top-level object
   # It's installed in the method-hash of the singleton-class of the
top level object.
end

But this is not true (because of top-level magic, about which I just
posted a lament). The method foo is installed as if in "class Object
... end":

    def foo ; "foo" ; end
    self.singleton_methods.include? "foo" -> false
    Object.methods.include? "foo" -> true (in irb)

(All of which contributes to my confusion about "instance_eval", alas.)

···

--
Posted via http://www.ruby-forum.com/\.

9

Setting aside my confusion about top-level "def"s (which may be
orthogonal to my questions about "instance_eval"):

Rick Denatale wrote:

rb_obj_instance_eval sets the klass argument to the singleton_class of
the receiver (creating it if it doesn't already exist), unless the
receiver is an immediate object (a Fixnum, or nil, true, or false) in
which case it sets klass to nil.

I would have guessed that the klass argument would be the context in
which constants and "def"s are evaluated. But we've already seen that
this is not true (re the constants).

So far as I can guess, this klass argument seems to affect "def"s AND
NOTHING ELSE. Can that be? (If so, all my questions are answered. But
I may have a comment or two.)

···

--
Posted via http://www.ruby-forum.com/\.

10

Rick Denatale wrote:

Now all this begged a question in my mind. That is, what's the
difference between instance_eval and class_eval (with its alias
module_eval). A little digging in the 1.8.6 MRI code reveals that
both use the same underlying code, but the inner c function
specific_eval (in eval.c) takes both a klass and a self argument.

Both rb_object_instance_eval (the code behind Kernel#instance_eval)
and rb_mod_module_eval (the code behind both Module#module_eval and
Module#class_eval) set the self argument to the receiver.

rb_obj_instance_eval sets the klass argument to the singleton_class of
the receiver (creating it if it doesn't already exist), unless the
receiver is an immediate object (a Fixnum, or nil, true, or false) in
which case it sets klass to nil.
...

Very nice analysis work; with the Figure 24.2 (made famous by Gregg) of
the Pickaxe at hand, and Rick's detailed description of the klass
pointer adventures, we can now connect the dots (at least, most of
them).

Bravo!

Raul

···

--
Posted via http://www.ruby-forum.com/\.

11

Raul Parolari wrote:

we can now connect the dots (at least, most of them).

Ah, but I still wonder what the internal variable 'klass' affects. So
far, 'klass' seems to affect:

    - where a def method is stored
    - where constants in string evals are looked up

But I don't know.

···

--
Posted via http://www.ruby-forum.com/\.