On 28.01.2012, at 01:53, Mario Lanza wrote:
>=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 chain.  When you inherit a class from another class and then =
add a mixin, the mixin is not able to supercede the methods defined in =
the inherited-from class.

You mean the class itself, not an inherited class, as your example =
shows. An included module is inserted just above the class in the lookup =
chain.

> I dunno if Ruby's current behavior is intentional (having purposeful =
benefits) but I find it annoying as it makes it difficult to override a =
behavior 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 dilemma when dealing with vendor libraries.


It is intentional, and the change would breaking. Consider Array, for =
example: it implements #each, and by that contract, includes Enumerable. =
However, in addition to using the Enumerable methods, Array overrides =
some of them for performance reasons. Hash does it to return Hashes =
rather than Arrays, like Enumerable does, and so on. Proposed change =
would require changing that. In short, the problem would then be that =
you wouldn't be able to override module behaviour.=20

Arguably, the problem is about equivalent either way around, but there's =
no clear advantage to go changing things especially considering how much =
code would need to be changed.

There're several solutions to your dilemma of overriding behavior in =
third-party libraries, if you really wish to do so: you can extend =
individual objects with the module (extend includes into the singleton =
class); you can simply inherit and override; you can inherit and thereby =
create a slot for modules in-between the original and your subclass; you =
can use composition instead of inheritance,  =85


--