From: Daniel Brockman Date: 2005-07-29T20:13:36+09:00 Subject: Re: What's so special about operators, built-in classes and modules? gabriele renzi writes: >>> 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.) > > The point is that once you introduce MI Once we introduce *unified* MI. Face it: We already have MI, in one form or another. What about calling it "multiclass inheritance", or MCI? (By the way, Matz has since given a good, tangible reason for not unifying: It's not clear what should happen if you inherit from both Array and Hash, which are special types.) > (which is a simpler concept than single-class-inheritance- > with-modules-mixed-in) you bring a lot of new concepts > with it, i.e. > > - repeated inheritance No. [ruby-talk:149932] > - diamond inheritance No. [ruby-talk:149845] > - more complex semantics for "super", Super would still call the next method. > both in his class usage What is "his class usage"? > and for builtin overriding What is "builtin overriding"? > - how should the mwethod resolution work? As it does now, by linearizing depth-first. > Should it have a fixed order Yes, for some values of "fixed". > be user-updateable? Yes, for some values of "user-updateable". > In one case it would be less useful, in the other you > would need to add another concept No, we don't need any new concepts. > - ..the same for class functions, maybe Yes, as discussed elsewhere in this thread, singleton methods on modules are a problem, but a solution does not have to introduce any new concepts. For example, one possible solution is to make modules behave in this regard as classes currently do. > - maybe we could add a way to use a rename+select thing > like in Eiffel, That sounds cool, and I'll probably be all for it. However, it is irrelevant to this discussion. > but would it play nicely with ruby's dynamic nature? Why not? > and probably some more things. Probably not. > Mind you, I agree that in a theoretical non-ruby language > MI would be nice ;) Are you thinking of any particular "theoretical non-ruby language"? -- Daniel Brockman So really, we all have to ask ourselves: Am I waiting for RMS to do this? --TTN.