Re: Namespacing a class

2010/6/24 Caleb Clausen <[e-mail]>:
> On 6/22/10, J=C3=B6rg W Mittag <[e-mail]> wrote:
>> Gary Wright wrote:
>>> On Jun 21, 2010, at 3:35 PM, J=C3=B6rg W Mittag wrote:
>>>> Eric MSP Veith wrote:
>>>>> Modules are used for mixins. Is it possible -- and does it make sense=
 at
>>>>> all
>>>>> - -- to mixin a class into another class? I guess not?
>>>> Actually, to add a bit to Brian's answer: it *is* possible and makes
>>>> perfect sense. It's just not allowed in Ruby, but it *is* allowed in
>>>> other languages.
>>> Allowing classes to mixin other classes would change the class
>>> hierarchy from a tree to a directed acyclic graph. =C2=A0As soon as you
>>> do that you have to figure out how to manage the method lookup
>>> process along multiple paths. I don't think there is any sort of
>>> consensus on how to do that (i.e. different languages take
>>> different approaches) and so I'm not sure 'makes perfect sense' is
>>> an accurate characterization of the solution space for that
>>> problem.
>>
>> You can take the algorithm Ruby uses for mixins and simply substitute
>> classes for modules and it would work exactly the way it does today,
>> including the linearization property.
>>
>> The way mixins work in Ruby is (roughly) as follows (assume that we
>> want to mix =E2=9F=A6M=E2=9F=A7 into a class =E2=9F=A6C=E2=9F=A7, ignore=
 for a moment the case of
>> mixing a mixin into another mixin):
>>
>> 1. create an anonymous class =E2=9F=A6I=E2=9F=A7
>> 2. set =E2=9F=A6I=E2=9F=A7's method table pointer to =E2=9F=A6M=E2=9F=A7=
's method table
>> 3. set =E2=9F=A6I=E2=9F=A7's superclass to the =E2=9F=A6C=E2=9F=A7's sin=
gleton class's superclass
>> 4. set =E2=9F=A6C=E2=9F=A7's singleton class's superclass to =E2=9F=A6I=
=E2=9F=A7
>>
>> In other words: create an anonymous class with the same methods but a
>> different identity as the mixin and insert it in the ancestor chain
>> directly above the singleton class.
>>
>> There's really no need here for =E2=9F=A6M=E2=9F=A7 to be a module, it c=
ould just as
>> well be a class. The linearization property depends on the fact that
>> mixin inclusion is done via a freshly minted anonymous class which has
>> no ancestors or descendants of its own: the include class =E2=9F=A6I=E2=
=9F=A7 *only*
>> gets the methods from the mixin, it does not get its place in the
>> inheritance hierarchy. Whether the method table that =E2=9F=A6I=E2=9F=A7=
 points to
>> used to belong to a module or a class is really irrelevant. It's just
>> a bag of methods.
>>
>> The case of mixing in a mixin into another mixin is also handled
>> similar to the way it is today: currently, when you mix a module into
>> a module, it gets inserted above the module like it would above a
>> class. And then, when you mix a module =E2=9F=A6M=E2=9F=A7 into a *class=
*, Ruby not
>> only constructs an include class for the =E2=9F=A6M=E2=9F=A7's method ta=
ble, but
>> recursively also for all modules mixed into =E2=9F=A6M=E2=9F=A7. Note th=
at this means
>> that this mixin chain is only walked *once*, when you include =E2=9F=A6M=
=E2=9F=A7 into
>> the class. If you later mix other modules into =E2=9F=A6M=E2=9F=A7, thei=
r methods will
>> *not* be available to instances of the class.
>>
>> Again, it would be possible to do just the same thing with classes
>> instead of modules: walk the chain of include classes and simply clone
>> them, then inject them into the ancestors chain like above.
>>
>> That's what I meant by "makes perfect sense": you can take the exact
>> same algorithm that Ruby currently uses for module inclusion and use
>> it for class inclusion with the exact same results.
>
> What you describe might work well enough for pure-ruby classes, but if
> you tried to mix a core class (Array, String) into another class, the
> result would be segfaults. Maybe the same would be true of any class
> implemented in C? Not sure.

I believe the more important point is that - although classes and
modules have only few differences (inheritance, instance creation) -
they are deliberately kept separate because they are language
artifacts intended to model different concepts (entities vs.
behavior).  Even if it is technically possible to mix in classes the
same way as modules (and I believe J=C3=B6rg's assessment is correct here)
it probably does not make much sense to allow this from a conceptual
point of view.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/