Re: singleton methods vs. meta instance methods

Brian Candler wrote:
> Daniel DeLorme wrote:
>> Furthermore this does not happen with builtin classes.
> 
> I'm not sure what you mean by that part. I get the same if I use String 
> instead of your class A:

You're right, I can't reproduce this anymore. It seems I got confused at
some point in my irb session.

> But notice what happens if I try an *instance* of String (which is 
> comparable to what you were doing with an *instance* of class Object)
> 
> a = String.new
> a_meta = (class << a;self;end)
> def a.foobar; end
> p a.singleton_methods(false)
> p a_meta.instance_methods(false)
> 
> ["foobar"]
> ["split", "rstrip!", "to_sym", "swapcase", "chop", "foobar", "empty?", 
[snip]
> "to_str", "%", "delete", "tr_s!"]
> 
> So you can see the instance methods of the object's metaclass include 
> the instance methods of that object's class. From one point of view this 
> seems reasonable to me; the metaclass is like a 'private subclass' to 
> the real class.
> 
>>From another point of view, you might expect instance_methods(false) not 
> to return those methods. But I think that just explains why we have a 
> separate singleton_methods method - if you *really* want just the 
> singleton methods, not including the methods of the concrete class, call 
> that.

Thank you for the explanation, it does make a lot more sense now. I'm of
the second point of view; I would expect instance_methods(*true*) to
return those extra methods, but not instance_methods(*false*). But POLS
is relative, and now that I understand this behavior I can see why the
"allocate", "new" and "superclass" methods were present in A's singleton
class' instance methods; those are indeed the instance methods defined
in Class:
   Class.instance_methods(false) #=> ["allocate", "superclass", "new"]

So it seems that
   x.meta.instance_methods(false) == x.singleton_methods +
   x.class.instance_methods(false)

I was missing that last part...

Daniel