From: Daniel DeLorme Date: 2008-12-14T19:51:53+09:00 Subject: 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