Hi there.

For me, your diagram is perfectly correct (however I had some doubts at 
the beginning again).

Well, I wouldn't say that now all cases are covered, even though it 
looks like they are. But the diagram is not good for framing and putting 
on the wall, it is only good for learning from it. Because there are 
special cases like:

class<<nil;self;end  #=> NilClass
class<<true;self;end #=> TrueClass

This kind of primitives appears not to have eigenclass at all, but there 
is only one instance of each of the NilClass, FalseClass and TrueClass, 
so it's not a problem. Still methods can be added to these primitives.

class<<5;end    # raises TypeError: no virtual class for Fixnum

This primitive doesn't have eigenclass at all, you cannot add methods to 
one particular instance of Fixnum. You cannot even _be_ inside this 
nonexistent singleton class.

Also, have a look at this case:

eval("def q;end",nil.instance_eval{binding})

It raises an error. There's a place (inside the eval), where you _can_ 
be, but cannot define a method. So I guess juggling with bindings can 
produce some more cases.

> Is def the only method that uses the current class value?

I suppose yes (probably alias also). But in fact it's not a method, not 
even a private one. It must be something else, that cannot be hacked 
easily (oh no, are there such things in Ruby?).

I must say I definitely learnt something from your question.

TPR

--
http://al2o3-cr.blogspot.com/
-- 
Posted via http://www.ruby-forum.com/.