On Thu, 21 Aug 2003, Pit Capitain wrote: > On 21 Aug 2003 at 10:51, Mathieu Bouchard wrote: > > I'm trying to figure out the feasibility of > > merging the Module class with the Class class, with all the consequent > > changes, and with as much backward compatibility as possible. > > (...) > Mathieu, could you tell us what you are trying to achieve? I suppose > you want to unify some core Ruby concepts, but I could be wrong or > only grasp a part of your ideas. 1. unification of concepts that are very close to each other and for which the distinction introduces just more rules and so little advantages. 2. simplification of ruby (see #1) -- how long does it take me to explain thoroughly Ruby's inheritance mechanisms to someone else. Also eliminates the question of whether starting by explaining SI and then adding "mixins", or starting with MI and talk about the constraints. In either case it's too long and usually ends with "why?" "just because.". 3. there's a problem with advocacy (incl helping newbies). When asked whether Ruby is SI or MI, what are we supposed to answer? What I've quite often seen is something along the lines of "it's 0.5(S+M)I", which then degenerates into heavy thesaurizing like, they're not abstract classes, you should say "modules" or "mixins", and modules ain't inherited, you should instead say they're "included into" or "extended into" or "mixed into". "are you telling me to do two jobs for the same salary?" "no, i'm telling you to absorb his function... in an absorptive fashion, using osmosis, symbiosis, and synergy." "can you change reality by giving new names to ordinary things?" -- dilbert 2003.07.21 4. convenience and sanity. it's annoying having to distinguish between modules, classes. When you speak of a module as a category that contains also classes, then you have to specify "non-Class Modules", but usually it's understood that what is called a module is not a class, even though the Module class inherits from the Class class; but then how do you talk of modules in general, where classes are also part of the set? Note that in those sentences I'm sweating hard avoiding the word "include" because I don't want to confuse matters further with several meanings of "include". Do we have a problem with terminology here? > Nonetheless, I find this very interesting and worthwhile, but doubt > that such a change would ever be incorporated in the language. The > distinction between classes and modules (not the namespace usage, but > the mixins) seems to be too fundamental a concept in Ruby. So maybe a > merge might only happen, if at all, in the interpreter. I have been listing the consequences of such a change in the previous mail. I also have been listing exhaustively the differences between Module and Class in the mail before that. I don't know how you say that it's too fundamental; I would expect justifications. The way I see it, you'd still be able to do "mixins", except they would bear a more common name, "multiple inheritance". > Do you think it's possible in current Ruby to replace every > class/module design into one which uses only modules for inheritance > and classes only to create instances? Can you all think of something > that wouldn't be possible in such a design? In the Ruby I know, this is a transform that can be done, with the exception of metaclass inheritance (there is no metamodule inheritance). This means that "class methods" of a non-Class Module don't get inherited by sub-Modules. If a given class hierarchy doesn't use metaclass inheritance, then the normalization you suggest is very much straightforward. Otherwise you may have to resort to tricks like making metaclasses inherit from another module by using "extend" inside of a "module" block. (I recall doing this at some point) Once the code is normalized into all modules and minimal use of classes, then you can do everything the same as in my proposal, save for small syntax details. ________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju