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

On 28.01.2012, at 01:53, Mario Lanza wrote:
> 
> 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. 

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,  


--