From: Daniel Brockman Date: 2005-07-29T08:31:05+09:00 Subject: Re: What's so special about operators, built-in classes and modules? Yukihiro Matsumoto writes: Matz> I don't understand why this issue [class/module Matz> unification] arises again and again. I know that the issue has come up a number of times before, and that you have been opposed to the idea each time. I appreciate that you let people like me continue to whine about it on this list. (If this were emacs-devel, RMS would have killed this thread the minute he saw it emerge.) Matz> _I_ encourage mixin inheritance. Yes, and that's the strongest argument in favor of mixins (i.e., separate non-class modules) that I've seen so far. Matz> It is powerful enough to solve the problem in single Matz> inheritance (sharing code between classes beyond Matz> inheritance line, without copy&paste). Agreed. It *is* powerful enough. Matz> It is much simpler and easier to use than Matz> 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? (Yes, I'm beating at a straw man here, but I'm only doing it because I don't see anything else around to beat at.) Matz> Why people want "real" multiple inheritance by Matz> unifying classes and modules, when Ruby's mixin Matz> 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. Matz> Why people want unnecessary complexity? Matz> Just because other languages do? I'm curious. Unnecessary complexity is exactly what I do *not* want. I am under the belief that we currently have it. Austin Ziegler writes: AZ> This is just my opinion, Matz, and not any particular AZ> insight into Daniel's or Devin's thinking, but it's AZ> based on the common patterns that I've seen between AZ> people who tend to advocate the unification of class AZ> and module. AZ> AZ> It seems to me that these people are interested in Ruby AZ> becoming theoretically conceptually clean as well as AZ> pragmatically clean. That's a nice way of putting it, but I'd put it in terms of orthogonality instead of cleanliness, because "clean" is such a loaded and inexact word. [Using ASCII quotes now, Nikolai, out of respect to everyone who can't deal with Unicode. I'll annoy them more later.] AZ> It seems to me that they're saying "these things are AZ> *almost* the same; why can't they be the same?" Exactly. At least, that's what I'm thinking. :-) AZ> This is without regard for the practical problems of AZ> such unification, but purely for the aesthetic AZ> theoretical cleanliness. Ignoring for a while the fact that theoretical uncleanliness is itself a practical problem for whoever is confused by it, I am more than willing to discuss the practical problems of the unification (and I'm sure there are some). AZ> This is part of the reason I responded to Daniel a while AZ> back saying that I couldn't see a single reason for the AZ> unification of the two concepts. I still can't. To which I replied that you were "forcing me to assume that you were shying away from the truth." I regret using such harsh language, because I later realized that when you said that you "can't see a single reason," you didn't mean that you ignored the reasons I was putting before you, but that you were simply unconvinced by them. Austin, if I offended you, I sincerely apologize. -- Daniel Brockman So really, we all have to ask ourselves: Am I waiting for RMS to do this? --TTN.