[#41916] Proposal: Bitmap Marking GC — Narihiro Nakamura <authornari@...>

Hi.

18 messages 2012/01/05

[#41941] [ruby-trunk - Bug #5851][Open] make check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame *** — Vit Ondruch <v.ondruch@...>

12 messages 2012/01/06

[#41979] [ruby-trunk - Bug #5865][Open] Exception#== should return false if the classes differ — Hiro Asari <asari.ruby@...>

10 messages 2012/01/08

[#42003] [ruby-trunk - Bug #5871][Open] regexp \W matches some word characters when inside a case-insensitive character class — Gareth Adams <gareth@...>

14 messages 2012/01/09

[#42016] [ruby-trunk - Feature #5873][Open] Adopt FFI over DL — Heesob Park <phasis@...>

15 messages 2012/01/10

[#42149] [ruby-trunk - Feature #5899][Open] chaining comparsions. — Ondrej Bilka <neleai@...>

12 messages 2012/01/16

[#42164] [ruby-trunk - Feature #5903][Open] Optimize st_table (take 2) — Yura Sokolov <funny.falcon@...>

18 messages 2012/01/17

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

From: Eero Saynatkari <ruby-ml@...>
Date: 2012-01-28 11:31:20 UTC
List: ruby-core #42253
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


--


In This Thread