From: luke gruber <luke.gru@...>
Date: 2011-08-22T05:26:35+09:00
Subject: Re: Gritty Details of super()

>extend Mod

Thanks Gavin and Robert.

Yeah, I knew that extend would do the trick as it includes the instance 
methods of the module in the singleton class of the extended object, but 
was wondering this: if you include a module that defines a singleton 
method, and since the included module 'effectively becomes the 
superclass of whatever class included it (pickaxe)', then calls to super 
should resolve at the 'effective superclass', no?

On looking into it further though, when a module is included it isn't 
'literally' a superclass, as in all calls to Child.superclass will not 
resolve at the included module, even though that module, upon inclusion, 
created an anonymous class directly above the class that included the 
module.

In the example that Robert gave above, on line 22
>22  p Test.superclass

Right now it's Object, which I understand. But if we also include Mod, 
wouldn't that make the superclass of Test some anonymous class that 
proxies to Mod?

But it doesn't... It's still Object.

So I guess what's weird is that Ruby is creating a superclass when we 
include a module, but that superclass is skipped with calls to 
superclass.

And when people say that super goes looking in the superclass, that is 
not true. It looks in the ancestors, because clearly super can resolve 
to anonymous superclasses (included modules, extended modules) as in the 
example that Robert gave.

hehe, if anyone is still reading this rambling stuff, I appreciate it.

-Luke

-- 
Posted via http://www.ruby-forum.com/.