From: Daniel Brockman Date: 2005-07-29T13:20:24+09:00 Subject: Re: What's so special about operators, built-in classes and modules? Yukihiro Matsumoto writes: >>> It is much simpler and easier to use than >>> multiple inheritance. >> >> This is where our minds go apart. Is it because unifying >> classes and modules would *enable* you to do weird things >> like inheriting from both Array and Hash? I honestly >> don't think anyone ever tried to do that, and I don't >> think anyone would expect it to work in a useful manner. >> Do you? > > If it is not impossible, the language should define the > behavior for it. If it is possible to inherit from Array > and Hash, _I_ have to do something. Just do basically what you'd do if they were modules. > Unifying them gives me too heavy burden. The burden is not on you to make every string of valid Ruby code do something useful. Okay, wait a minute... I think I'm starting to see the real problem here. I'm not very familiar with Ruby's internals, but I know arrays and hashes are special fundamental types. If you do "class Foo < Array", will instances of Foo be ordinary objects or will they be T_ARRAYs? >>> Why people want "real" multiple inheritance by unifying >>> classes and modules, when Ruby's mixin inheritance works >>> quite well? >> >> Because it would do the same thing, only in a >> simpler way. I hesitate to invoke Occam's Razor, but >> it's definitely about orthogonality of concepts. > > Pardon me? You feel multiple inheritance simpler? > > It has fewer restriction, more general, but not simpler, > both in concept and implementation. I think it is simpler in concept. I believed it was no more or less simple in implementation until I considered the issue I mentioned above. > Perhaps we are using the term "simple" in > different manner. That would certainly explain a few things. All else being equal, I consider "fewer concepts" to imply "more simple". (All else would not be equal in this case, but in my mind very little would change.) > When they would do almost the same thing, and when mixin > inheritance is much simpler to understand (for me at > least), Ah, this may be the heart of the controversy. Some people consider mixin inheritance much simpler to understand, while others consider it just unnecessarily complicated. Maybe it *is* just a matter of taste. > far easier to implement, I can't comment on that. Hats off to you. :-) > why should I implement multiple inheritance? From your point of view, there seems to be no reason to. On the contrary, it seems positively undesirable. Thank you for taking the time to discuss this matter. -- Daniel Brockman