From: gwtmp01@...
Date: 2007-01-24T04:37:42+09:00
Subject: Re: inheritance concept in ruby


On Jan 23, 2007, at 10:35 AM, Helder Ribeiro wrote:

> dblack@wobblini.net wrote:
>
>> I don't think anyone came up with a strictly technical, bullet-proof
>> objection to class/module unification when Mathieu was advocating it.
>> Basically, if all the modules in the lookup-path were, instead,
>> classes, I don't think anything we can do now would be impossible
>> (assuming the lookup rules were preserved).  In that sense the
>> presence of the difference is more a matter of semantic enrichment
>> than technical extension.
>
> Perfect! That was exactly what I was beginning to think. You summed it
> up very well :-)


I've been meaning to followup on this discussion.

I also chewed on the idea that modules and classes were a needless
division for quite a while but I've come to appreciate the differences
if not from a theoretical sense certainly from a practical sense.

In any case, one thing that I think is distinctly different between
modules and classes is that classes are placed inside a tree structure
when they are *defined* but that the relationship between modules is
much more dynamic as it depends on the execution of the 'include'
method.

So classes always spring into existence as a leaf on the inheritance
tree while modules are independent objects until they are explicitly
included into another module, which may never happen at all.

I haven't sorted out in my mind all the implications but it feels
like this introduces an important semantic difference.

Also the semantics of 'include' create something that is more
constrained than an arbitrary DAG (directed acyclical graph).  At
least I think so.   MI would permit the creation of completely
general DAGs.  So this also leads me to believe that there are
theoretical as well as practical differences between MI and mixin
strategies.


Gary Wright