# Instance\_eval/class\_eval including/extending modules

**URL:** <https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757>\
**Category:** ruby-talk\
**Created:** [30 August 2008 21:08 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757 "2008-08-30T21:08:18Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Pedro\_Silva](https://avatars.discourse-cdn.com/v4/letter/p/4da419/32.png) [@Pedro\_Silva](https://rubytalk.org/u/Pedro_Silva)\
**Post date:** [30 August 2008 21:08 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/1 "2008-08-30T21:08:18Z")

</div>

Consider the following example:

&nbsp;&nbsp;module SomeModule  
&nbsp;&nbsp;&nbsp;&nbsp;def some\_method  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;puts "Some Method - #{self}"  
&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;end

&nbsp;&nbsp;class SomeClass  
&nbsp;&nbsp;&nbsp;&nbsp;def self.metaclass  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class \<\< self; self; end  
&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;end

&nbsp;&nbsp;SomeClass.instance\_eval {include SomeModule} # instance method  
&nbsp;&nbsp;SomeClass.instance\_eval {extend SomeModule} # singleton method (class  
method)  
&nbsp;&nbsp;SomeClass.metaclass.instance\_eval {include SomeModule} # class method

Using instance\_eval on SomeClass sets the "ghost class" to be the  
current class, so using include shouldn't put the methods on "ghost  
class" instead of SomeClass (SomeClass class methods)? In this case  
using instance\_eval or class\_eval has the same result, depending only if  
we're using include or extend.

AFAIK the "problem" has to do with value of self, because private  
methods are invoked on self (default receiver), so using instance\_eval  
or class\_eval won't matter as self will be SomeClass in both cases.  
That's why calling include in instance\_eval/class\_eval on metaclass  
(self is now the "ghost class") is the same as using extend when self is  
SomeClass.

I'm using Ruby 1.8.6 and at least to me this seems kind of a strange  
behaviour because using def or define\_method will have different results  
if we use instance\_eval. Does Ruby 1.9 maintains this behaviour?

In my humble opinion would make more sense if instance\_eval/class\_eval  
maintain the same behaviour on all methods and not the "special"  
behaviour on private methods. Can someone enlight me?

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).

---

<div class="post-metadata">

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\
**Post date:** [31 August 2008 07:42 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/2 "2008-08-31T07:42:48Z")

</div>

HI --

> Consider the following example:
> 
> module SomeModule  
> &nbsp;&nbsp;&nbsp;def some\_method  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;puts "Some Method - #{self}"  
> &nbsp;&nbsp;&nbsp;end  
> end
> 
> class SomeClass  
> &nbsp;&nbsp;&nbsp;def self.metaclass  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class \<\< self; self; end  
> &nbsp;&nbsp;&nbsp;end  
> end
> 
> SomeClass.instance\_eval {include SomeModule} # instance method  
> SomeClass.instance\_eval {extend SomeModule} # singleton method (class  
> method)  
> SomeClass.metaclass.instance\_eval {include SomeModule} # class method
> 
> Using instance\_eval on SomeClass sets the "ghost class" to be the  
> current class, so using include shouldn't put the methods on "ghost  
> class" instead of SomeClass (SomeClass class methods)? In this case  
> using instance\_eval or class\_eval has the same result, depending only if  
> we're using include or extend.

I'm not sure what you mean by "ghost class". I think that might be an  
unnecessary extra term.

> AFAIK the "problem" has to do with value of self, because private  
> methods are invoked on self (default receiver), so using instance\_eval  
> or class\_eval won't matter as self will be SomeClass in both cases.  
> That's why calling include in instance\_eval/class\_eval on metaclass  
> (self is now the "ghost class") is the same as using extend when self is  
> SomeClass.

That's true all the time: mixing a module into an object's singleton  
class is the same as extending the object with that module. In both  
cases, the module gets inserted in the object's method lookup path  
between the singleton class and the original class.

> I'm using Ruby 1.8.6 and at least to me this seems kind of a strange  
> behaviour because using def or define\_method will have different results  
> if we use instance\_eval. Does Ruby 1.9 maintains this behaviour?

Yes, and that's really part of the point of having both instance\_eval  
and class\_eval. I don't think there's any advantage to merging them  
into one behavior. Just choose the one you need in a given case.

> In my humble opinion would make more sense if instance\_eval/class\_eval  
> maintain the same behaviour on all methods and not the "special"  
> behaviour on private methods. Can someone enlight me?

I don't really see the anomaly you're seeing, but let me outline the  
rules that are followed (which, in the case of instance\_eval, have  
nothing to do with whether or not the object is a class), and maybe  
that will clear it up or at least simplify it.

obj.instance\_eval {...} sets self to obj during the block. Instance  
methods defined in the block are singleton methods of obj (i.e.,  
instance methods of obj's singleton class).

c.class\_eval sets self to c during the block. Instance methods defined  
in the block are instance methods of c.

I think everything you're seeing can be accounted for by those rules.

David

> **···**
>
> On Sun, 31 Aug 2008, Pedro Silva wrote:
> 
> --  
> Rails training from David A. Black and Ruby Power and Light:  
> &nbsp;&nbsp;&nbsp;Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL  
> &nbsp;&nbsp;&nbsp;Advancing with Rails January 19-22 Fort Lauderdale, FL \*  
> &nbsp;&nbsp;&nbsp;\* Co-taught with Patrick Ewing!  
> See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!

---

<div class="post-metadata">

**Author:** ![Pedro\_Silva](https://avatars.discourse-cdn.com/v4/letter/p/4da419/32.png) [@Pedro\_Silva](https://rubytalk.org/u/Pedro_Silva)\
**Post date:** [31 August 2008 18:42 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/3 "2008-08-31T18:42:41Z")

</div>

David, thanks for your reply.

> I'm not sure what you mean by "ghost class". I think that might be an  
> unnecessary extra term.

What I meant by "ghost class" was singleton class or eigenclass. I've  
already seen different names for the class that Ruby creates when we use  
instance\_eval or define singleton methods.

> Yes, and that's really part of the point of having both instance\_eval  
> and class\_eval. I don't think there's any advantage to merging them  
> into one behavior. Just choose the one you need in a given case.

I'm not saying they should have the same behaviour in that sense, I was  
trying to say that they should have the same behaviour no matter what is  
the method visibility - private vs others. As matter of fact I think  
using instance\_eval or class\_eval with include/extend should have  
different results.

SomeClass.instance\_eval {include SomeModule} has the same result as  
SomeClass.class\_eval {include SomeModule}

> I don't really see the anomaly you're seeing, but let me outline the  
> rules that are followed (which, in the case of instance\_eval, have  
> nothing to do with whether or not the object is a class), and maybe  
> that will clear it up or at least simplify it.

The example above showed me the "special case" between private methods  
and other methods. Let me see if I can write an example that shows what  
I'm trying to say. I think the best way is using def vs define\_method.

&nbsp;&nbsp;SomeClass.instance\_eval { def class\_method; puts "Class Method"; end }  
&nbsp;&nbsp;SomeClass.instance\_eval do  
&nbsp;&nbsp;&nbsp;&nbsp;define\_method(:instance\_method) {puts "Instance Method"}  
&nbsp;&nbsp;end

&nbsp;&nbsp;SomeClass.class\_method  
&nbsp;&nbsp;SomeClass.new.instance\_method

At least for me this is not something I would expect. When I define a  
method using instance\_eval I expect to have a singleton method (class  
method in this case). The problem here has to do with self and what is  
the current class, self is still SomeClass so define\_method creates an  
instance method, but because current class is the singleton class, using  
def is the same as creating a class method. I guess this happen because  
define\_method is a private method. So in my opinion private methods have  
different treatment from regular methods.

I hope I expressed myself in the right manner what I was trying to say  
(i'm not a native english speaker, portuguese actually :p). If you could  
tell me what you think about that I'll appreciate that.

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).

---

<div class="post-metadata">

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\
**Post date:** [31 August 2008 20:02 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/4 "2008-08-31T20:02:18Z")

</div>

Hi --

> David, thanks for your reply.
> 
> > I'm not sure what you mean by "ghost class". I think that might be an  
> > unnecessary extra term.
> 
> What I meant by "ghost class" was singleton class or eigenclass. I've  
> already seen different names for the class that Ruby creates when we use  
> instance\_eval or define singleton methods.
> 
> > Yes, and that's really part of the point of having both instance\_eval  
> > and class\_eval. I don't think there's any advantage to merging them  
> > into one behavior. Just choose the one you need in a given case.
> 
> I'm not saying they should have the same behaviour in that sense, I was  
> trying to say that they should have the same behaviour no matter what is  
> the method visibility - private vs others. As matter of fact I think  
> using instance\_eval or class\_eval with include/extend should have  
> different results.
> 
> SomeClass.instance\_eval {include SomeModule} has the same result as  
> SomeClass.class\_eval {include SomeModule}
> 
> > I don't really see the anomaly you're seeing, but let me outline the  
> > rules that are followed (which, in the case of instance\_eval, have  
> > nothing to do with whether or not the object is a class), and maybe  
> > that will clear it up or at least simplify it.
> 
> The example above showed me the "special case" between private methods  
> and other methods. Let me see if I can write an example that shows what  
> I'm trying to say. I think the best way is using def vs define\_method.
> 
> SomeClass.instance\_eval { def class\_method; puts "Class Method"; end }  
> SomeClass.instance\_eval do  
> &nbsp;&nbsp;&nbsp;define\_method(:instance\_method) {puts "Instance Method"}  
> end
> 
> SomeClass.class\_method  
> SomeClass.new.instance\_method
> 
> At least for me this is not something I would expect. When I define a  
> method using instance\_eval I expect to have a singleton method (class  
> method in this case). The problem here has to do with self and what is  
> the current class, self is still SomeClass so define\_method creates an  
> instance method, but because current class is the singleton class, using  
> def is the same as creating a class method. I guess this happen because  
> define\_method is a private method. So in my opinion private methods have  
> different treatment from regular methods.
> 
> I hope I expressed myself in the right manner what I was trying to say  
> (i'm not a native english speaker, portuguese actually :p). If you could  
> tell me what you think about that I'll appreciate that.

I don't think there's any special case for private methods. They get  
called on 'self', just as they always do. And if you instance\_eval a  
class, "def" does exactly what it does when you instance\_eval any  
object: it creates a singleton method.

Keep in mind that so-called "class methods" are essentially just  
singleton methods of instances of Class. (The only special case  
behavior is the fact that subclasses of class C can call class C's  
class methods.)

Like most questions in Ruby, it comes down to: classes are objects too  
🙂 I don't think instance\_eval does anything special with classes.  
The only special thing you'd want to do is to be able to create  
instance methods, and class\_eval handles that case.

David

> **···**
>
> On Mon, 1 Sep 2008, Pedro Silva wrote:
> 
> --  
> Rails training from David A. Black and Ruby Power and Light:  
> &nbsp;&nbsp;&nbsp;Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL  
> &nbsp;&nbsp;&nbsp;Advancing with Rails January 19-22 Fort Lauderdale, FL \*  
> &nbsp;&nbsp;&nbsp;\* Co-taught with Patrick Ewing!  
> See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!

---

<div class="post-metadata">

**Author:** ![Pedro\_Silva](https://avatars.discourse-cdn.com/v4/letter/p/4da419/32.png) [@Pedro\_Silva](https://rubytalk.org/u/Pedro_Silva)\
**Post date:** [31 August 2008 20:22 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/5 "2008-08-31T20:22:36Z")

</div>

Thanks once again for the fast reply,

> I don't think there's any special case for private methods. They get  
> called on 'self', just as they always do. And if you instance\_eval a  
> class, "def" does exactly what it does when you instance\_eval any  
> object: it creates a singleton method.

In my opinion define\_method and def executed in the same context should  
have the same behaviour, but they don't. The reason def creates a  
singleton method is because the current class is set to the singleton  
class so there's where the method will be defined, but self remains the  
instance\_eval receiver.

> Keep in mind that so-called "class methods" are essentially just  
> singleton methods of instances of Class. (The only special case  
> behavior is the fact that subclasses of class C can call class C's  
> class methods.)

I know that, that's why I said singleton methods (class methods).

> Like most questions in Ruby, it comes down to: classes are objects too  
> 🙂 I don't think instance\_eval does anything special with classes.  
> The only special thing you'd want to do is to be able to create  
> instance methods, and class\_eval handles that case.

I guess I was unable to express correctly my point. I know that  
class\_eval lets create instance methods (that's why the receiver must be  
a class) and instance\_eval singleton methods (on classes means class  
methods). My problem is having instance\_eval with def creating singleton  
methods but with define\_method creating instance methods. I expected to  
have def and define\_method to have the same result on the same context,  
but they don't.

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).

---

<div class="post-metadata">

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\
**Post date:** [31 August 2008 20:33 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/6 "2008-08-31T20:33:43Z")

</div>

Hi --

> Thanks once again for the fast reply,
> 
> > I don't think there's any special case for private methods. They get  
> > called on 'self', just as they always do. And if you instance\_eval a  
> > class, "def" does exactly what it does when you instance\_eval any  
> > object: it creates a singleton method.
> 
> In my opinion define\_method and def executed in the same context should  
> have the same behaviour, but they don't. The reason def creates a  
> singleton method is because the current class is set to the singleton  
> class so there's where the method will be defined, but self remains the  
> instance\_eval receiver.

Yes, that's the rule, and it's followed for all objects. It sounds  
like you want a special case for instance\_eval on class objects, so  
that they somehow don't realize that define\_method is being called on  
them, and I don't think that's a good idea. It's better to keep the  
definition of the instance\_eval context consistent: self is swapped to  
the receiver, and 'def' applies to the receiver's singleton class.  
That accounts for everything that currently happens, and it makes no  
difference whether it's a class object or some other object.

> > Keep in mind that so-called "class methods" are essentially just  
> > singleton methods of instances of Class. (The only special case  
> > behavior is the fact that subclasses of class C can call class C's  
> > class methods.)
> 
> I know that, that's why I said singleton methods (class methods).
> 
> > Like most questions in Ruby, it comes down to: classes are objects too  
> > 🙂 I don't think instance\_eval does anything special with classes.  
> > The only special thing you'd want to do is to be able to create  
> > instance methods, and class\_eval handles that case.
> 
> I guess I was unable to express correctly my point. I know that  
> class\_eval lets create instance methods (that's why the receiver must be  
> a class) and instance\_eval singleton methods (on classes means class  
> methods). My problem is having instance\_eval with def creating singleton  
> methods but with define\_method creating instance methods. I expected to  
> have def and define\_method to have the same result on the same context,  
> but they don't.

I understand your point, but I don't like the idea of introducing the  
special case. Remember that the point of define\_method is that it's a  
method, with method semantics and local scope in its code-block. It's  
not supposed to be identical to def, and it has very different uses.

For the case where self is the class and define\_method and def behave  
similarly, there's class\_eval. Instead of having instance\_eval treat  
classes as a special case, which would be inconsistent and confusing,  
there's a separate method for doing something very similar to a  
'class' block, but with a code block.

David

> **···**
>
> On Mon, 1 Sep 2008, Pedro Silva wrote:
> 
> --  
> Rails training from David A. Black and Ruby Power and Light:  
> &nbsp;&nbsp;&nbsp;Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL  
> &nbsp;&nbsp;&nbsp;Advancing with Rails January 19-22 Fort Lauderdale, FL \*  
> &nbsp;&nbsp;&nbsp;\* Co-taught with Patrick Ewing!  
> See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!

---

<div class="post-metadata">

**Author:** ![Pedro\_Silva](https://avatars.discourse-cdn.com/v4/letter/p/4da419/32.png) [@Pedro\_Silva](https://rubytalk.org/u/Pedro_Silva)\
**Post date:** [31 August 2008 20:40 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/7 "2008-08-31T20:40:26Z")

</div>

Really fast this time. 😉

> For the case where self is the class and define\_method and def behave  
> similarly, there's class\_eval. Instead of having instance\_eval treat  
> classes as a special case, which would be inconsistent and confusing,  
> there's a separate method for doing something very similar to a  
> 'class' block, but with a code block.

I understand, I guess I can't distinguish very well self from current  
class concept. Can you explain the difference?

One last question to see if I understand all this correctly. Private  
methods are invoked on self, other non-private methods are invoked on  
current class?

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).

---

<div class="post-metadata">

**Author:** ![Patrick\_Li](https://avatars.discourse-cdn.com/v4/letter/p/e36b37/32.png) [@Patrick\_Li](https://rubytalk.org/u/Patrick_Li)\
**Post date:** [1 September 2008 02:15 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/8 "2008-09-01T02:15:40Z")

</div>

I must say that I also find the difference between  
instance\_eval/class\_eval and include/extend extremely confusing.

If someone clearly knows the fundamental rules, please please share.

Here's my understanding:

def myMethod; end  
&nbsp;&nbsp;-creates a method "myMethod" callable by instances of self.

Here's a list of situations that I'm having trouble with:

1) class Klass  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def myMethod; end  
&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;-self is equal to Klass  
&nbsp;&nbsp;-so myMethod() is callable by Klass.new

2) Klass.instance\_eval {def myMethod; end}

-self is equal to Klass  
-so myMethod() is callable by Klass.new \<-- this isn't true

What's wrong with my understanding? I think I'm not understanding def  
correctly.

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).

---

<div class="post-metadata">

**Author:** ![Dave\_Mail\_Archive](https://avatars.discourse-cdn.com/v4/letter/d/f04885/32.png) [@Dave\_Mail\_Archive](https://rubytalk.org/u/Dave_Mail_Archive)\
**Post date:** [1 September 2008 02:29 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/9 "2008-09-01T02:29:26Z")

</div>

Ruby has two separate concepts: self, the current object, and 'the current class', which isn't represented by an externally visible variable. Methods are stored in the later, independent of the value of self. It \_is\_ confusing, but you can always remember that class\_eval creates instance methods and instance\_eval creates class methods. There are actually good reasons why this is so.

If you want to get deeper into this, \<pimp\>I could recommend a certain set of screencasts...\</pimp\>

Dave

> **···**
>
> On Aug 31, 2008, at 9:15 PM, Patrick Li wrote:
> 
> > I must say that I also find the difference between  
> > instance\_eval/class\_eval and include/extend extremely confusing.
> > 
> > If someone clearly knows the fundamental rules, please please share.
> > 
> > Here's my understanding:
> > 
> > def myMethod; end  
> > -creates a method "myMethod" callable by instances of self.
> > 
> > Here's a list of situations that I'm having trouble with:
> > 
> > 1) class Klass  
> > &nbsp;&nbsp;&nbsp;&nbsp;def myMethod; end  
> > &nbsp;&nbsp;end
> > 
> > -self is equal to Klass  
> > -so myMethod() is callable by Klass.new
> > 
> > 2) Klass.instance\_eval {def myMethod; end}
> > 
> > -self is equal to Klass  
> > -so myMethod() is callable by Klass.new \<-- this isn't true
> > 
> > What's wrong with my understanding? I think I'm not understanding def  
> > correctly.

---

<div class="post-metadata">

**Author:** ![\_Pena\_Botp1](https://avatars.discourse-cdn.com/v4/letter/_/94ad74/32.png) [@\_Pena\_Botp1](https://rubytalk.org/u/_Pena_Botp1)\
**Post date:** [1 September 2008 02:48 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/10 "2008-09-01T02:48:24Z")

</div>

# I must say that I also find the difference between  
# instance\_eval/class\_eval and include/extend extremely confusing.  
# If someone clearly knows the fundamental rules, please please share.  
# Here's my understanding:  
# def myMethod; end  
# -creates a method "myMethod" callable by instances of self.  
# Here's a list of situations that I'm having trouble with:  
# 1) class Klass  
# def myMethod; end  
# end  
# -self is equal to Klass  
# -so myMethod() is callable by Klass.new

generally, callable by instances of Klass

# 2) Klass.instance\_eval {def myMethod; end}  
# -self is equal to Klass  
# -so myMethod() is callable by Klass.new

no.  
the instance here is Klass, not those created/instanciated w Klass.new. So you are creating a class method for Klass. Remember, classes are objects too, ergo there are class methods too.

# What's wrong with my understanding? I think I'm not understanding def  
# correctly.

observe eg,

class Klass  
&nbsp;&nbsp;def mymethod; end  
end  
#=\> nil

k=Klass.new  
#=\> #\<Klass:0x28e1ff0\>

k.mymethod  
#=\> nil

ok. fine.  
let's try the other way, ie instance\_eval.

k.instance\_eval{def mymethod3; end}  
#=\> nil

k.mymethod3  
#=\> nil

fine still.  
now let us try it for Klass itself.

Klass.mymethod  
NoMethodError: undefined method `mymethod' for Klass:Class

oops 😉  
maybe, we can do it w mymethod3

Klass.mymethod3  
NoMethodError: undefined method `mymethod3' for Klass:Class

oops still 😉

Ok. let us define a method that works only for Klass.

Klass.instance\_eval{def mymethod2; end}  
#=\> nil

k.mymethod2  
NoMethodError: undefined method `mymethod2' for #\<Klass:0x28e1ff0\>

heheh, it does not work for instances/creations of Klass.  
now, let us test it for Klass itself.

Klass.mymethod2  
#=\> nil

ah, we see.

hth.  
kind regards -botp

> **···**
>
> From: Patrick Li [[mailto:patrickli\_2001@hotmail.com](mailto:patrickli_2001@hotmail.com)]

---

<div class="post-metadata">

**Author:** ![Patrick\_Li](https://avatars.discourse-cdn.com/v4/letter/p/e36b37/32.png) [@Patrick\_Li](https://rubytalk.org/u/Patrick_Li)\
**Post date:** [1 September 2008 02:50 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/11 "2008-09-01T02:50:19Z")

</div>

Ahhh... now it comes together. Thank you so much.

so here's a quick revision of my understanding:

I'm gonna call the 'the current class' selfClass.

1)  
class Klass  
&nbsp;&nbsp;\<-- self is Klass  
&nbsp;&nbsp;\<-- selfClass is also Klass  
end

2)  
def myMethod; end \<-- creates myMethod(), callable by selfClass.new

3)  
obj.instance\_eval \<-- sets self to obj, sets selfClass to obj's  
metaclass

4)  
obj.class\_eval \<-- sets self to obj, AND sets selfClass to obj

5)  
include myModule \<-- evaluates the instructions in myModule, underneath  
selfClass

6)  
extend myModule \<-- evaluates the instructions in myModule, underneath  
self

Does that seem correct now? Thanks for your help by the way. That's  
quite a bit more clear now.

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).

---

<div class="post-metadata">

**Author:** ![Dave\_Mail\_Archive](https://avatars.discourse-cdn.com/v4/letter/d/f04885/32.png) [@Dave\_Mail\_Archive](https://rubytalk.org/u/Dave_Mail_Archive)\
**Post date:** [1 September 2008 03:21 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/12 "2008-09-01T03:21:56Z")

</div>

No evaluation takes place. The module is already "compiled", and Ruby simply links a proxy for that module in to the parent class chain for either the class or metaclass. That way, module functionality is shared between multiple classes/objects that include/extend the module.

Dave

> **···**
>
> On Aug 31, 2008, at 9:50 PM, Patrick Li wrote:
> 
> > 5)  
> > include myModule \<-- evaluates the instructions in myModule, underneath  
> > selfClass
> > 
> > 6)  
> > extend myModule \<-- evaluates the instructions in myModule, underneath  
> > self
> > 
> > Does that seem correct now? Thanks for your help by the way. That's  
> > quite a bit more clear n

---

<div class="post-metadata">

**Author:** ![Patrick\_Li](https://avatars.discourse-cdn.com/v4/letter/p/e36b37/32.png) [@Patrick\_Li](https://rubytalk.org/u/Patrick_Li)\
**Post date:** [1 September 2008 03:47 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/13 "2008-09-01T03:47:25Z")

</div>

Now that I have a firmer grasp on Ruby's object system, is it possible  
to combine some of these methods, so that they're easier to understand?

Here's some changes that can be made:

Let me know what you think  
&nbsp;&nbsp;-Patrick

What it does:  
Combines eval/instance\_eval/class\_eval into one consistent method  
Combines include/extend into one consistent method

Changes:

eval(proc)  
-eval is now a method of Object. This ALWAYS sets self to the receiver  
object,

and then evaluates proc.

def myMethod  
-def is now a method of Module. This creates a method named myMethod()  
that

can be called by instances of the receiver.

Consequences: This means that if self is not a subclass of Module, you  
cannot

call def. Instead I propose a metaclass method that returns an objects

metaclass.

So instead of:  
obj.instance\_eval do  
&nbsp;&nbsp;def myMethod; end  
end

you MUST do:  
obj.metaclass.instance\_eval do  
&nbsp;&nbsp;def myMethod; end  
end

include myModule  
-becomes a method of Object. This method puts the method definitions in  
myModule into the receiver object.

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).

---

<div class="post-metadata">

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\
**Post date:** [1 September 2008 08:26 UTC](https://rubytalk.org/t/instance-eval-class-eval-including-extending-modules/48757/14 "2008-09-01T08:26:39Z")

</div>

HI --

> Now that I have a firmer grasp on Ruby's object system, is it possible  
> to combine some of these methods, so that they're easier to understand?
> 
> Here's some changes that can be made:
> 
> Let me know what you think  
> -Patrick
> 
> What it does:  
> Combines eval/instance\_eval/class\_eval into one consistent method  
> Combines include/extend into one consistent method

It's not right to say that these things are inconsistent. They're all  
different from each other, and they all do things that make sense and  
are needed frequently. include and extend are related, but they're not  
in conflict; they're complementary, and they both do extremely useful  
things.

> Changes:
> 
> eval(proc)  
> -eval is now a method of Object. This ALWAYS sets self to the receiver  
> object,
> 
> and then evaluates proc.
> 
> def myMethod  
> -def is now a method of Module. This creates a method named myMethod()  
> that
> 
> can be called by instances of the receiver.
> 
> Consequences: This means that if self is not a subclass of Module, you  
> cannot
> 
> call def. Instead I propose a metaclass method that returns an objects
> 
> metaclass.

Join the club 🙂 Well, I call it Object#singleton\_class, but there's  
been a request pending for this method for years.

> So instead of:  
> obj.instance\_eval do  
> def myMethod; end  
> end
> 
> you MUST do:  
> obj.metaclass.instance\_eval do  
> def myMethod; end  
> end

Why? What's the advantage of taking away the current instance\_eval  
scenario?

> include myModule  
> -becomes a method of Object. This method puts the method definitions in  
> myModule into the receiver object.

I think you're trying to squeeze things together too tightly. Right  
now they're pretty well-engineered to handle the major use-cases and  
not to overlap with each other. I'd recommend living with them a  
little longer, and playing around with them a bit -- I think you'll  
see that they're all pulling their weight pretty well.

David

> **···**
>
> On Mon, 1 Sep 2008, Patrick Li wrote:
> 
> --  
> Rails training from David A. Black and Ruby Power and Light:  
> &nbsp;&nbsp;&nbsp;Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL  
> &nbsp;&nbsp;&nbsp;Advancing with Rails January 19-22 Fort Lauderdale, FL \*  
> &nbsp;&nbsp;&nbsp;\* Co-taught with Patrick Ewing!  
> See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!