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