Hi --

On Mon, 1 Sep 2008, Pedro Silva wrote:

> 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
>    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

-- 
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!