Having some confusions with the accesses to the methods in Module from the instances of Class

I am having some confusions with the accesses to the methods in Module
from the instances of Class.

I was tying to find the answers as below :

class C;end
C.superclass # => Object
Module.superclass # => Object
C.ancestors # => [C, Object, Kernel, BasicObject]
C.method(:ancestors).owner # => Module
C.included_modules # => [Kernel]

But I didn’t get my answers.

Questions :

(a) How the Module class is related with class C,as I am being able to
access the methods defined in Module using C?
(b) Why all Module instances methods become class method of class C?
Like I can call C.ancestors,whereas it is defined in Module as
Module#ancestors. Why all Module#meth_names becomes class methods of the
instances of Class,like C here?

Love U Ruby wrote in post #1124529:

I am having some confusions with the accesses to the methods in Module
from the instances of Class.

I was tying to find the answers as below :

class C;end
C.superclass # => Object
Module.superclass # => Object
C.ancestors # => [C, Object, Kernel, BasicObject]
C.method(:ancestors).owner # => Module
C.included_modules # => [Kernel]

But I didn’t get my answers.

Questions :

(a) How the Module class is related with class C,as I am being able to
access the methods defined in Module using C?
(b) Why all Module instances methods become class method of class C?
Like I can call C.ancestors,whereas it is defined in Module as
Module#ancestors. Why all Module#meth_names becomes class methods of the
instances of Class,like C here?

Possibly from this?

Class.ancestors
#=> [Class, Module, Object, Kernel, BasicObject]

It would appear that Class extends Module.

Matthew K. wrote in post #1124540:

Love U Ruby wrote in post #1124529:

Possibly from this?

Class.ancestors
#=> [Class, Module, Object, Kernel, BasicObject]

It would appear that Class extends Module.

module M
def foo
“12”
end
end
class C
extend M
end
C.foo # => “12”

class D
include M
end

D.new.foo # => “12”

Yes,as per the above example and you,it seems to me that,Module instance
methods became class methods of Class. In my example

class C;end

C is an instance of Class. Then C.ancestors should throw error. I am
missing the connection… please help

On Tue, Oct 15, 2013 at 7:29 AM, Love U Ruby [email protected]
wrote:

class D
include M
end

D.new.foo # => “12”

Yes,as per the above example and you,it seems to me that,Module instance
methods became class methods of Class.

No. By extending any object with a module instance methods defined
in the module become methods of the object - even if that object is a
class as in your case. That means, they are inserted in the
inheritance hierarchy of the singleton class:

irb(main):001:0> module F
irb(main):002:1> def foo; 123 end
irb(main):003:1> end
=> nil
irb(main):004:0> o = Object.new.extend F
=> #Object:0x0000060003db98
irb(main):005:0> o.singleton_class.ancestors
=> [F, Object, Kernel, BasicObject]

Do not confuse Class with “a class”. Class is the class of any class:

irb(main):010:0>
ObjectSpace.each_object(Class).each_with_object(Hash.new(0)) {|c,h|
h[c.class] += 1}
=> {Class=>407}

In my example

class C;end

C is an instance of Class. Then C.ancestors should throw error.

Why?

I am missing the connection…

Yes, it seems so. You need to be aware that there is a (or at least
one, depending how you look at it) cycle in Ruby’s class hierarchy.
Some lines as food for thought

irb(main):011:0> Object.ancestors
=> [Object, Kernel, BasicObject]
irb(main):012:0> Object.class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]
irb(main):013:0> Class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]
irb(main):014:0> BasicObject.class
=> Class
irb(main):015:0> Class.class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]
irb(main):016:0> Class.class
=> Class

Note line 16.

Cheers

robert

On Tue, Oct 15, 2013 at 4:04 PM, Haig D. [email protected]
wrote:

Robert,

Thanks for explaining this.

You’re welcome.

As I continue to soak in Ruby, it appears there’s now a preference favoring the
use of Mixins rather than direct inheritance. I understand that such a strategy
can help optimize application decoupling and keep your code DRY. I guess the trick
is knowing when to use inheritance and when to include one or more modules.

Any insights regarding this?

https://www.ruby-forum.com/topic/4417159

Cheers

robert

Robert,

Thanks for explaining this.

As I continue to soak in Ruby, it appears there’s now a preference
favoring the use of Mixins rather than direct inheritance. I understand
that such a strategy can help optimize application decoupling and keep
your code DRY. I guess the trick is knowing when to use inheritance and
when to include one or more modules.

Any insights regarding this?

– Haig

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs