Can anyone explain how Ruby’s mixin system is better than regular
multiple inheritance? What’s the difference between:
···
module Parent1
def amb_func
puts "in parent1"
end
end
module Parent2
def amb_func
puts "in parent2"
end
end
class Child
include Parent1, Parent2
end
Child.new.amb_func
and
class Parent1
def amb_func
puts "in parent1"
end
end
class Parent2
def amb_func
puts "in parent2"
end
end
class Child < Parent1, Parent2
end
Child.new.amb_func
Aside from the fact that the second example obviously isn’t valid
Ruby, how is the first scenario an improvement over the second? The
first outputs “in parent2” and I assume the second would as well. Can
somebody please explain this?
In message “How are mixins better than multiple inheritance?” on 04/05/26, Bill Atkins dejaspam@batkins.com writes:
Can anyone explain how Ruby’s mixin system is better than regular
multiple inheritance? What’s the difference between:
Mix-in is no better than multiple inheritance, because mix-in is just a
usage of multiple inheritance. You can do mix-in by multiple
inheritance. Ruby forces mix-in to make it hard to “abuse” multiple
inheritance.
Can anyone explain how Ruby’s mixin system is better than regular
multiple inheritance? What’s the difference between:
module Parent1
def amb_func
puts “in parent1”
end
end
module Parent2
def amb_func
puts “in parent2”
end
end
class Child
include Parent1, Parent2
end
Child.new.amb_func
and
class Parent1
def amb_func
puts “in parent1”
end
end
class Parent2
def amb_func
puts “in parent2”
end
end
class Child < Parent1, Parent2
end
Child.new.amb_func
Aside from the fact that the second example obviously isn’t valid
Ruby, how is the first scenario an improvement over the second? The
first outputs “in parent2” and I assume the second would as well. Can
somebody please explain this?
Mix-in is no better than multiple inheritance, because mix-in is just a
usage of multiple inheritance. You can do mix-in by multiple
inheritance. Ruby forces mix-in to make it hard to “abuse” multiple
inheritance.
The difference for me has been mainly conceptual. I consider mixins
to be:
Primarily functional. You’re mixing in functions.
Stateless. There are no class-level variables with mixins.
Mixins anticipate and make use of methods in some future class that
mixes them in.
As assertions, these are patently untrue; you can end up mixing in
class-level variables in Ruby, and the mixed in methods don’t ever
have to access any external methods. However, these are the
characteristics that I generally associate with mixins.
Inheritance, multiple or single, has different general
characteristics:
Stateful. You are inheriting not only behavior, but state.
Ignorance on the inheritee of the inheritor.
In Ruby, there is nothing that you can do with one that you can’t do
with the other – except for multiplicity – so there is no practical
difference. I believe that the conceptual difference is useful,
though.
Can anyone explain how Ruby’s mixin system is better than regular
multiple inheritance? What’s the difference between:
module Parent1
def amb_func
puts “in parent1”
end
end
module Parent2
def amb_func
puts “in parent2”
end
end
class Child
include Parent1, Parent2
end
Child.new.amb_func
and
class Parent1
def amb_func
puts “in parent1”
end
end
class Parent2
def amb_func
puts “in parent2”
end
end
class Child < Parent1, Parent2
end
Child.new.amb_func
Aside from the fact that the second example obviously isn’t valid
Ruby, how is the first scenario an improvement over the second? The
first outputs “in parent2” and I assume the second would as well. Can
somebody please explain this?
Apparently the inclusion sequence differs if you have two separate include
statements vs. one statement with two modules.
Yes, I thought so (and tested all variants indeed), but OP had posted
the same code I tryed, and had different output. Probably the behavior
of this construction is not defined by the language. Or he just didn’t try
his own code.
Can anyone explain how Ruby’s mixin system is better than regular
multiple inheritance? What’s the difference between:
module Parent1
def amb_func
puts “in parent1”
end
end
module Parent2
def amb_func
puts “in parent2”
end
end
class Child
include Parent1, Parent2
end
Child.new.amb_func
and
class Parent1
def amb_func
puts “in parent1”
end
end
class Parent2
def amb_func
puts “in parent2”
end
end
class Child < Parent1, Parent2
end
Child.new.amb_func
Aside from the fact that the second example obviously isn’t valid
Ruby, how is the first scenario an improvement over the second? The
first outputs “in parent2” and I assume the second would as well. Can
somebody please explain this?