From: "David A. Black" <dblack@...>
Date: 2005-07-18T11:11:14+09:00
Subject: Re: alias of some methods does not work

Hi --

On Mon, 18 Jul 2005, gga wrote:

>
>
>
>> Because those don't belong to Kernel. They belong to the class Module...
>>
>> irb(main):015:0> class Module
>> irb(main):016:1> alias :meths :instance_methods
>> irb(main):017:1> end
>> => nil
>> irb(main):018:0> Module.meths
>> => ["send", "name", "class_eval", "object_id", "...etc....
>>
>> Zach
>
> Ok... but color me confused.  Kernel is a module which has those
> functions I could not alias.  How does a module inherit functions from
> a class?

Because Kernel is an instance of the class Module.  So to the extent
that Module defines instance methods for its instances, Kernel gets
those methods.

There is then the separate question of Kernel defining *its* instance
methods (which in fact then propagate to all objects, since that's
what Kernel is for).

What you're seeing is some of the dual-role-ness of modules and
classes: they are storage spaces for instance methods which will be
imparted to other objects, but they are also, themselves, objects, and
can therefore have instance methods which are imparted to them by
*their* classes.

So, Kernel being an instance of Module, if you have:

   class Module
     def instance_methods
       # insert definition here
     end
   end

then Kernel itself -- the actual object Kernel -- will have that
method.

That's different from the next phase, which is Kernel defining
instance methods for other objects (which it can do, because it is a
module):

   module Kernel
     def methods        # the one you aliased successfully, I believe
       # insert definition here
     end
   end

Once that happens, any object on which you bestow the instance methods
of Kernel (which happens to be all objects, though with most modules
that isn't the case) will have a method called "methods".

This is about the most convoluted this gets, since you're dealing with
Kernel, methods called "methods", etc.  In general, the business of
having classes and modules be objects in their own right is an
extremely powerful and -- believe it or not -- simplifying principle.

> Also, why does Kernel.ancestors not show this relationship?
> If I do Module.ancestors, it shows Kernel instead as one of its

The object model chases its own tail a bit, at the top of the tree,
for the sake of bootstrapping the whole of object-space into
existence.  You've got things like: Object is a class, but classes are
instances of the class Object.  That's because if the object Class (of
which all other classes are instances) wanted to be an object, but
there was no Object class for it to be an instance of -- while Object
couldn't exist, because it's a class and there was no Class class for
*it* to be an instance of -- the whole thing would never get started.

So you will see a certain amount of these circular relationships, but
only at the top of the chart.  Once the whole thing gets going, it
works very consistently.  (See the diagram and commentary in object.c
for more details.)


David

-- 
David A. Black
dblack@wobblini.net