Difference between inheritance and mixin

Ruby
1

Hai friends,
Can anybody can answer this question.
what is the difference between inheritance and mixin.
what is the use of mixin and what is the use of inheritance.

Inheritance is we are deriving the superclass.
for example,I did like this,

cass A
def B
puts ‘a and b’
end
end
class C < A
def D
puts ‘d’
end
end
e=C.new
e.B
e.D
The output should be like this,
a and b
d
I know very vell about the inheritance,but both the
cases we are using but Idon’t about the mixin and difference two
methods.

by
vellingiri

2

what is the use of mixin and what is the use of inheritance

“Programming Ruby (2nd)” :

p 119:
In fact, mixed-in modules effectively behave as superclasses."

p. 355:
If a module is included in a class definition, the module’s constants,
class variables, and instance methods are effectively bundled into an
anonymous(and inaccessible) superclass for that class…Calls to
methods not defined in the class will be passed to the module(s) mixed
into the class before being passed to any parent class.

module Greet
def friendly_greet
puts “Hello.”
end

def angry_greet
puts “Go away.”
end

end

class NicePerson
include Greet
end

class MadPerson
include Greet
end

class SadPerson
include Greet

def friendly_greet
puts “Cry, hi, cry.”
end

end

np = NicePerson.new
np.friendly_greet #Hello.
puts

mp = MadPerson.new
np.angry_greet #Go away.
puts

sp = SadPerson.new
sp.friendly_greet #Cry, hi, cry.
sp.angry_greet #Go away.

3

On Sep 26, 12:06 am, Vellingiri A. [email protected]
wrote:

Hai friends,
Can anybody can answer this question.
what is the difference between inheritance and mixin.
what is the use of mixin and what is the use of inheritance.

Mixin modules are searched before the parent class.

Also, you can only inherit from one parent class, but you can mixin
many modules to the same class.

Because modules cannot inherit from other modules or classes, there is
no problem of ‘diamond’ inheritance.

4

Hi –

On Wed, 26 Sep 2007, Phrogz wrote:

Also, you can only inherit from one parent class, but you can mixin
many modules to the same class.

Because modules cannot inherit from other modules or classes, there is
no problem of ‘diamond’ inheritance.

Modules can mix in modules, though, so you could have:

          module M

 module N         module O

           class C

But the diamond problem is avoided by having the order of mixing in be
significant, so that there’s no ambiguity about which module/class is
to be searched.

David

5

what is the use of mixin and what is the use of inheritance

class FourLeggedAnimal
def speed
puts “I run fast.”
end
end

class Mammal
def birth
puts “My babies don’t hatch from eggs.”
end
end

class Dog < FourLeggedAnimal
def speak
puts “Bark, bark.”
end
end

d = Dog.new
d.speak
d.speed
d.birth

–output:–
Bark, bark.
I run fast.
r6test.rb:21: undefined method `birth’ for #Dog:0x251ac
(NoMethodError)

class FourLeggedAnimal
def speed
puts “I run fast.”
end
end

module Mammal
def birth
puts “My babies don’t hatch from eggs.”
end
end

class Dog < FourLeggedAnimal
include Mammal

def speak
puts “Bark, bark.”
end
end

d = Dog.new
d.speak
d.speed
d.birth

–ouput:–
Bark, bark.
I run fast.
My babies don’t hatch from eggs.

6

On 9/26/07, Vellingiri A. [email protected] wrote:
I see that you got some good answers on this already, I find the
following text very interesting, maybe it gives you some useful
background information about Mixins and why they are er bad. (Well but
much less than MI).

http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf

HTH
Robert

7

On 9/26/07, David A. Black [email protected] wrote:

          module M

 module N         module O

           class C

But the diamond problem is avoided by having the order of mixing in be
significant, so that there’s no ambiguity about which module/class is
to be searched.

On the other hand, Ruby has varied semantics for different versions
of structures like this:

   Module M
                 \
                  Class C
                       |
                  Class D
  Module M  |
                \     |
                Class E

If M defines a method m and D overrides m, it’s version dependent
which definition instances of E get. At least for a while in the 1.9
history, it would get the original version back, which seems to be the
‘correct’ semantics to me. Last time I checked though 1.9 went back
to ignoring the re-inclusion.

Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/