SuperClass and Modules

[Shilesh Kumar]

Hi,

I am very much new to Ruby

Ruby Consider Modules as super classes [Internally].
My confusion is that there can be many modules either included or
extended to a Ruby class where as only one Parent class is allowed [as
in java] in Ruby... why so..? Is it something to do with Meta classes in
Ruby.. ?

Thanks,
-shyl.

 

[Pedro Silva]

Hi Shilesh,

My confusion is that there can be many modules either included or
extended to a Ruby class where as only one Parent class is allowed [as
in java] in Ruby... why so..?

Multiple inheritance has one big problem usually denominated as "the
diamond problem". Check this link:
http://en.wikipedia.org/wiki/Diamond_problem.
Ruby using single inheritance plus mixins gives almost the same
advantages without these problems.

Is it something to do with Meta classes in
Ruby.. ?

Metaclasses have nothing to do with it. A metaclass/ghost
class/singleton class/eigenclass is class that Ruby introduces in the
inheritance chain to allow to define singleton methods (object specific
methods), just that.

Pedro Silva.

 

[James Coglan]

[Note: parts of this message were removed to make it a legal post.]

Multiple inheritance has one big problem usually denominated as "the
diamond problem". Check this link:
http://en.wikipedia.org/wiki/Diamond_problem.
Ruby using single inheritance plus mixins gives almost the same
advantages without these problems.

You cannot have multiple inheritance without the diamond problem -- that
page actually mentions how Ruby resolves method names in this case:

module A; end
module B; include A; end
module C; include A; end

class D
include B
include C
end

Methods will be looked up in D, C, B and A (in that order) when you call a
method on an instance of D.

 

[Shilesh Kumar]

You cannot have multiple inheritance without the diamond problem -- that
page actually mentions how Ruby resolves method names in this case:

module A; end
module B; include A; end
module C; include A; end

class D
include B
include C
end

Methods will be looked up in D, C, B and A (in that order) when you call
a
method on an instance of D.

Thanks James and Pedro,

I understood the diamond problem.

let me clarify myself.

To avoid the method confusion while having more than one module, Ruby
looks in a particular order. This can be applied in the case of super
classes as well and let ruby follow the order of import while searching
for a method. Thus i may have,

class MyClass < A < B #[oder of method search will be from MyClass, A to
B]

I believe that there might be some strong reason for allowing multiple
Modules while restricting only one Parent ...?

 

[James Coglan]

[Note: parts of this message were removed to make it a legal post.]

To avoid the method confusion while having more than one module, Ruby
looks in a particular order. This can be applied in the case of super
classes as well and let ruby follow the order of import while searching
for a method. Thus i may have,

class MyClass < A < B #[oder of method search will be from MyClass, A to
B]

I believe that there might be some strong reason for allowing multiple
Modules while restricting only one Parent ...?

This is likely just my opinion, but it's mostly a question of semantics, of
indicating your intent to other programmers. If you want to make a more
specialised kind of MyClass object, you'd subclass MyClass. If you have some
behaviour that could be applied to many different types of objects, you use
a module and mix it in.

Parent-child inheritance is really just a special case of module inclusion,
with some extra restrictions. Remember that Class inherits from Module --
modules are objects that store methods, and classes are objects that store
methods *and* create new objects.

 

[Robert Klemme]

[Note: parts of this message were removed to make it a legal post.]

To avoid the method confusion while having more than one module, Ruby
looks in a particular order. This can be applied in the case of super
classes as well and let ruby follow the order of import while searching
for a method. Thus i may have,

class MyClass < A < B #[oder of method search will be from MyClass, A to
B]

I believe that there might be some strong reason for allowing multiple
Modules while restricting only one Parent ...?

This is likely just my opinion, but it's mostly a question of semantics, of
indicating your intent to other programmers. If you want to make a more
specialised kind of MyClass object, you'd subclass MyClass. If you have some
behaviour that could be applied to many different types of objects, you use
a module and mix it in.

+1

To throw in two other terms: this is inheritance as specialization (or
generalization, if you look the other direction) vs. implementation
inheritance.

Parent-child inheritance is really just a special case of module inclusion,
with some extra restrictions. Remember that Class inherits from Module --
modules are objects that store methods, and classes are objects that store
methods *and* create new objects.

Absolutely. You can also say: if multiple class inheritance was allowed
classes and modules would have even less distinctive features which
makes it less clear when to choose which. By having more differences
between the two design choices become clearer. My 0.02EUR...

Kind regards

robert