From: "David A. Black" <dblack@...>
Date: 2008-09-01T05:33:43+09:00
Subject: Re: instance_eval/class_eval including/extending modules

Hi --

On Mon, 1 Sep 2008, Pedro Silva wrote:

> 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

-- 
Rails training from David A. Black and Ruby Power and Light:
   Intro to Ruby on Rails  January 12-15   Fort Lauderdale, FL
   Advancing with Rails    January 19-22   Fort Lauderdale, FL *
   * Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!