«

irb(main):006:0> module Kernel
irb(main):007:1> alias :_methods :methods
irb(main):008:1> end

is all OK.

Yet:
irb(main):001:0> module Kernel
irb(main):002:1> alias :_instance_methods :instance_methods
irb(main):003:1> end
NameError: undefined method `instance_methods' for module `Kernel'
from (irb):2
from :0
irb(main):004:0> Kernel.instance_methods
=> ["freeze", "__id__", "singleton_methods", ...]

Is this by design or a bug? Why can't I alias any of the following:
# alias :_constants :constants
# alias :_instance_methods :instance_methods
# alias :_public_instance_methods ublic_instance_methods
# alias :_protected_instance_methods rotected_instance_methods
# alias :_private_instance_methods rivate_instance_methods
?

Reason I want to alias them is so that I can add some function into my
..irbrc so that those arrays get returned in sorted order automatically.

gga wrote:
> irb(main):006:0> module Kernel
> irb(main):007:1> alias :_methods :methods
> irb(main):008:1> end
>
> is all OK.
>
> Yet:
> irb(main):001:0> module Kernel
> irb(main):002:1> alias :_instance_methods :instance_methods
> irb(main):003:1> end
> NameError: undefined method `instance_methods' for module `Kernel'
> from (irb):2
> from :0
> irb(main):004:0> Kernel.instance_methods
> => ["freeze", "__id__", "singleton_methods", ...]
>
> Is this by design or a bug? Why can't I alias any of the following:
> # alias :_constants :constants
> # alias :_instance_methods :instance_methods
> # alias :_public_instance_methods ublic_instance_methods
> # alias :_protected_instance_methods rotected_instance_methods
> # alias :_private_instance_methods rivate_instance_methods
> ?

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

> 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? Also, why does Kernel.ancestors not show this relationship?
If I do Module.ancestors, it shows Kernel instead as one of its
ancestors. What kind of magic is going on behind the scenes here?

irb(main):001:0> Kernel.object_id
=> 20763780
irb(main):002:0> Kernel.class
=> Module

Kernel is a constant (like Math:I) that is an instance of Module.
ancestors is an instance method of Module, so it is available on Kernel.
Methods like 'puts' for example are module methods on Kernel. Meh, I'm
too tired to explain better than that right now. Start Googling.

Devin

gga wrote:

>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? Also, why does Kernel.ancestors not show this relationship?
>If I do Module.ancestors, it shows Kernel instead as one of its
>ancestors. What kind of magic is going on behind the scenes here?
>
>

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

GGarramuno wrote:
>
> 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? Also, why does Kernel.ancestors not show this relationship?
> If I do Module.ancestors, it shows Kernel instead as one of its
> ancestors. What kind of magic is going on behind the scenes here?
>


class Object
class << self
p [:A, self, ancestors]
#-> [:A, #<Class:Object>, [Class, Module, Object, Kernel]]
alias :_constants :constants
alias :_instance_methods :instance_methods
alias :_public_instance_methods ublic_instance_methods
alias :_protected_instance_methods rotected_instance_methods
alias :_private_instance_methods rivate_instance_methods
end
p [:B, self, ancestors] #-> [:B, Object, [Object, Kernel]]
alias :_methods :methods
end

klass = String
p klass._constants == klass.constants
p klass._instance_methods == klass.instance_methods
p klass._public_instance_methods == klass.public_instance_methods
p klass._protected_instance_methods == klass.protected_instance_methods
p klass._private_instance_methods == klass.private_instance_methods
p klass.new._methods == klass.new.methods
#-> true


daz