From: Daniel Brockman Date: 2005-07-29T12:53:53+09:00 Subject: Re: What's so special about operators, built-in classes and modules? "Ara.T.Howard" writes: > On Fri, 29 Jul 2005, Jim Weirich wrote: > >> The big problem with diamond inheritance is the question >> of instance data ... do you have one or two copies? > > sure... i just wast just trying to help the OP see that we > currently never actually end up with diamonds Thank you, but I do understand the concept of linearization, and maintain that it does not prevent diamond inheritance. > that require ruby to resolve the search order. > currently it is entirely up to programmer who can chose > based on the order of module inclusion. Why would it be any different if Class equalled Module? > for classes it's even simpler. in otherwords the search > order is always totally explicit and shown in the source > rather than implicit as defined by some search algorithim > used by the interpreter... The unification would not change this at all, in any way. Even if this syntax was added, class A < B, C, D ; end the order B, C, D would still be "totally explicit and shown in the source." > and, by extension, that making 'include' mean 'inherit' > would indeed setup a diamond issue that ruby would need to > handle implicitly (mi). I don't understand this. >> (and given the way Ruby handles instance variables, I >> find it hard to imagine the answer to this question would >> ever be two). > > that would certainly be confusing... Don't knock it 'til you try it. As Joel said, there's been talk of adding module-local instance variables. It seems we've finally been able to agree that Ruby does have diamond inheritance, and adding module-local instance variables would introduce a diamond-inheritance-related problem, but that problem is wholly unrelated to the class/module distinction. In fact, as irony would have it, that diamond inheritance problem would *only* affect modules, not classes! -- Daniel Brockman