Asp Forum - inheritance concept in ruby

Kumar Tnj

1/9/2007 11:34:00 AM

Hi,

Is ruby supports multiple inheritence.
I am the beginner of ruby.
simple code for ruby multiple inheritence.

Thanks & Regards,
Kumar

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

18 Answers

hemant

1/9/2007 11:43:00 AM

On 1/9/07, Kumar Tnj <senvenit2003@india.com> wrote:
> Hi,
>
> Is ruby supports multiple inheritence.
> I am the beginner of ruby.
> simple code for ruby multiple inheritence.
>
> Thanks & Regards,
> Kumar
>

multiple inheritence is not supported in Ruby. However via modules and
mixins ruby achieves almost the same functionality.

--
gnufied
-----------
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.

Wilson Bilkovich

1/9/2007 5:23:00 PM

On 1/9/07, Kumar Tnj <senvenit2003@india.com> wrote:
> Hi,
>
> Is ruby supports multiple inheritence.
> I am the beginner of ruby.
> simple code for ruby multiple inheritence.
>

To expand on what hemant said.. try running this code.

class Useless
def six
6
end
end

module AlsoUseless
def seven
7
end
end

class Thing < Useless
include AlsoUseless
def five
5
end
end

thing = Thing.new
puts thing.five
puts thing.six
puts thing.seven
puts Thing.ancestors.inspect # Useless and AlsoUseless are shown.

Helder Ribeiro

1/12/2007 12:37:00 AM

Wilson Bilkovich wrote:
> On 1/9/07, Kumar Tnj <senvenit2003@india.com> wrote:
> > Hi,
> >
> > Is ruby supports multiple inheritence.
> > I am the beginner of ruby.
> > simple code for ruby multiple inheritence.
> >
>
> To expand on what hemant said.. try running this code.
>
> class Useless
> def six
> 6
> end
> end
>
> module AlsoUseless
> def seven
> 7
> end
> end
>
> class Thing < Useless
> include AlsoUseless
> def five
> 5
> end
> end
>
> thing = Thing.new
> puts thing.five
> puts thing.six
> puts thing.seven
> puts Thing.ancestors.inspect # Useless and AlsoUseless are shown.

I'm also new to Ruby and I've never used anything with multiple
inheritance. This code is enlightening but I can't see how this is
different from multiple inheritance in practice except that AlsoUseless
is not a class and you don't use the '<' sign with it.

In which cases do the two scenarious (M.I. and mixins) cause different
behaviors? Is it only related to member visibility? If yes, how
exactly?

Thanks!

Helder

Gregory Brown

1/12/2007 1:05:00 AM

On 1/11/07, Helder Ribeiro <helder@gmail.com> wrote:

> I'm also new to Ruby and I've never used anything with multiple
> inheritance. This code is enlightening but I can't see how this is
> different from multiple inheritance in practice except that AlsoUseless
> is not a class and you don't use the '<' sign with it.

The real complication with multiple inheritance is that you end up
inheriting the ancestors of both parent classes.

When you use a mixin, the additional methods are tacked on to a class
in the heirarchy, rather than creating another set of ancestors.

Since modules live outside of the tree of inheritance, they can be
used to provide functionality without complicating the ancestry chain.

See Comparable and Enumerable for excellent and practical uses of modules.

> In which cases do the two scenarious (M.I. and mixins) cause different
> behaviors? Is it only related to member visibility? If yes, how
> exactly?

if:

A < B < C

and module D is mixed into C, there is still a single path back to A.

Had we used multiple inheritence (if it were possible), perhaps

F < E < D

so now, C has two distinct roots, A and F.

Now imagine circular dependencies and other complications. Scary! :)

So modules allow you to avoid the verbosity of interfaces without
complicating the chain of ancestors.

Wilson Bilkovich

1/12/2007 5:07:00 AM

On 1/11/07, Helder Ribeiro <helder@gmail.com> wrote:
>
> Wilson Bilkovich wrote:
> > On 1/9/07, Kumar Tnj <senvenit2003@india.com> wrote:
> > > Hi,
> > >
> > > Is ruby supports multiple inheritence.
> > > I am the beginner of ruby.
> > > simple code for ruby multiple inheritence.
> > >
> >
> > To expand on what hemant said.. try running this code.
> >
> > class Useless
> > def six
> > 6
> > end
> > end
> >
> > module AlsoUseless
> > def seven
> > 7
> > end
> > end
> >
> > class Thing < Useless
> > include AlsoUseless
> > def five
> > 5
> > end
> > end
> >
> > thing = Thing.new
> > puts thing.five
> > puts thing.six
> > puts thing.seven
> > puts Thing.ancestors.inspect # Useless and AlsoUseless are shown.
>
> I'm also new to Ruby and I've never used anything with multiple
> inheritance. This code is enlightening but I can't see how this is
> different from multiple inheritance in practice except that AlsoUseless
> is not a class and you don't use the '<' sign with it.
>
> In which cases do the two scenarious (M.I. and mixins) cause different
> behaviors? Is it only related to member visibility? If yes, how
> exactly?
>

Multiple Inheritance can be extremely complex, as Gregory Brown has pointed out.
One complication is that you now have to have rules to 'break ties'
when you write:
def hello
super
end

What if each of the parent classes has their own implementation of
'hello'. Which one is invoked? Mix-ins simplify this greatly, because
there is still only one unambiguous superclass.

If you have used Java, they are like having Interfaces containing
working code, as well as just a list of what should be implemented.

Helder Ribeiro

1/12/2007 6:58:00 PM

Wilson Bilkovich wrote:
> >
>
> Multiple Inheritance can be extremely complex, as Gregory Brown has pointed out.
> One complication is that you now have to have rules to 'break ties'
> when you write:
> def hello
> super
> end
>
> What if each of the parent classes has their own implementation of
> 'hello'. Which one is invoked? Mix-ins simplify this greatly, because
> there is still only one unambiguous superclass.

Ok, I see this is a problem with multiple-inheritance, but it doesn't
seem to me like one that using Modules solves. When checking another
discussion*, I went to the PickAxe to check method lookup with modules
and got this:

"The answer is that Ruby looks first in the immediate class of an
object, then in the
mixins included into that class, and then in superclasses and their
mixins. *If a class has
multiple modules mixed in, the last one included is searched first*."

That is, the exact same thing happens when you have a class include two
modules and both implement the 'hello' method. There is no self-evident
way of choosing, so you have to come up with an arbitrary choice like
that of order of call to 'include'.

>
> If you have used Java, they are like having Interfaces containing
> working code, as well as just a list of what should be implemented.

This is interesting. Does Ruby allow codeless methods in a module like
those of an java interface?

* The discussion I refer to is at
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/2f478cc54e2826a4/fd1ae73662ff8916?q=%22What%27s+so+special+about+operators%2C+built-in+classes+and+modules%3F%22&hl=en#fd1ae7...

I'm not done reading it yet but has been very enlightening so far. I
cite it so Kumar can take a look at it as I think it's related to this.
The next question that comes after the answer to "does it have multiple
inheritance" is "what's with those modules?!". I'll try and look up
more stuff so I don't repeat questions here. Thanks so far to those who
answered =)

Helder

Gregory Brown

1/12/2007 8:13:00 PM

On 1/12/07, Helder Ribeiro <helder@gmail.com> wrote:

> That is, the exact same thing happens when you have a class include two
> modules and both implement the 'hello' method. There is no self-evident
> way of choosing, so you have to come up with an arbitrary choice like
> that of order of call to 'include'.

Yes, this is true.

However the issue is rarely with immediate dependencies, but dependency chains.

I.e., with mixins,

If I have A->B->C and C mixes in D, then E

the lookup is C,E,D,B,A

which logically is quick intuitive if you think about it.

If I have A->B->C

and ?->D->C

and

?->E->C

Those two question marks represent two independent dependency chains
that you cannot be sure what they implement without knowing the
ancestors of each.

Since modules live outside of the hierarchy, you will only be likely
to run into this problem with bad design. The point of mixins (and
multiple inheritance) really, is to address orthogonal concerns. Name
collision is a sign of either a code smell, or just a really complex
system that is going to need a lot of thought to begin with.

Gregory Brown

1/12/2007 8:25:00 PM

On 1/12/07, Helder Ribeiro <helder@gmail.com> wrote:

> That is, the exact same thing happens when you have a class include two
> modules and both implement the 'hello' method. There is no self-evident
> way of choosing, so you have to come up with an arbitrary choice like
> that of order of call to 'include'.

To me, it's the most intuitive choice as it reflects intrepretation order

class Child < Parent #imbue with ancestry

include Foo # imbue with foo's definitions
include Bar # imbue with bar's definitions

def something # imbue with actual definition

end

end

All that is happening is Ruby's applying the changes as it sees them.

So the path there is super clear

Child -> Bar -> Foo -> Parent.

Maybe this is surprising to those working in non-interpreted languages
though. I'm not sure.

Per Velschow

1/12/2007 8:45:00 PM

> This is interesting. Does Ruby allow codeless methods in a module like
> those of an java interface?

That wouldn't make sense. The only reason for having methods defined
with no code is when you have static type checking as in Java. In Ruby
everything happens at run-time.

Gregory Brown

1/12/2007 9:09:00 PM

On Jan 12, 3:45 pm, "Per Velschow" <Per.Velsc...@gmail.com> wrote:
> > This is interesting. Does Ruby allow codeless methods in a module like
> > those of an java interface?That wouldn't make sense. The only reason for having methods defined
> with no code is when you have static type checking as in Java. In Ruby
> everything happens at run-time.

However, this is much more powerful, because it allows you to reference
methods in your modules that you
expect classes to implement.

For example, all you need is <=> to get all of Comparable, and #each
to get Enumerable.

Designing with this in mind can be *very* powerful

comp.lang.ruby

inheritance concept in ruby

Kumar Tnj

hemant

Wilson Bilkovich

Helder Ribeiro

Gregory Brown

Wilson Bilkovich

Helder Ribeiro

Gregory Brown

Gregory Brown

Per Velschow

Gregory Brown

x Login to ForumsZone