[ruby-core:42254] Re: [ruby-trunk - Bug #5940][Open] Resolve conflict between inheritance and mixins

What you want is a feature planned for Ruby 2.0 called Module#prepend (as c=
ompared to Module#include).

Konstantin

On Jan 28, 2012, at 00:53 , Mario Lanza wrote:

>=20
> Issue #5940 has been reported by Mario Lanza.
>=20
> ----------------------------------------
> Bug #5940: Resolve conflict between inheritance and mixins
> https://bugs.ruby-lang.org/issues/5940
>=20
> Author: Mario Lanza
> Status: Open
> Priority: Normal
> Assignee:=20
> Category:=20
> Target version:=20
> ruby -v: 1.9.2
>=20
>=20
> Some in the Ruby community (like Chad Fowler) have noticed issues around =
how Ruby attempts to transverse a method's pipeline up the inheritance chai=
n.  When you inherit a class from another class and then add a mixin, the m=
ixin is not able to supercede the methods defined in the inherited-from cla=
ss.
>=20
> I've demonstrated the issue here:
> https://gist.github.com/515856
>=20
> It would be nice if Ruby were to change its default inheritance behavior =
so that mixin do override a class's methods.  Essentially, the behavior wou=
ld treat inheritance in nearly the same manner that it treats mixins.
>=20
>  class Person < ActiveRecord::Base
>  end
>=20
> would be effectively treated, in a manner of speaking, as:
>=20
>  class Person
>    include ActiveRecord::Base
>  end
>=20
> (I would go so far as to say that we get rid of direct inheritance in fav=
or of always using mixins to accomplish our inheritance goals.  I do have a=
 reservation for how this would affect backwards compatibility.)
>=20
> I dunno if Ruby's current behavior is intentional (having purposeful bene=
fits) but I find it annoying as it makes it difficult to override a behavio=
r in third-party libraries.  When I own the classes, I can simply refactor =
them to prefer mixins as to avoid this issue, but this doesn't solve the di=
lemma when dealing with vendor libraries.
>=20
>=20
> --=20
> http://bugs.ruby-lang.org/
>=20