[ANN] Article: Seeing Metaclasses Clearly

[Christoph]

I disagree, thinking that mixins and multiple inheritance are not the
same thing, and should not be pointed as such.

I tend to agree with Mathieu that the semantically insistence that
Ruby's mixins
are NOT some kind of MI of presents itself as a language game to
apiece the java kraut. On the other hand Ruby’s "Module mixin" relation is
NOT transitive, making it strikingly different from (single or multiple)
inheritance (see for example [ruby-talk:32007])

Is'nt it Class#new ?

Mathieu might be nominally wrong, but he is right in pointing out that
the current distinction between
"meta Object" (the singleton class of the "Class" object "Object") and
the class "Class" is just an artifact
of the current implementation of Ruby’s Object model. Two or three years
ago I even cooked up a
semi working modification of the interpreter (translation: the resulting
interpreter finished without crashing
running a couple of simple scripts), such that "meta Object" == Class
was true.

The strongest argument against "meta Object" == Class are the current
class relations
Class < Module < Oject.
To resolve this we could subclass both Module and Class from Object
directly, or settle on relations
Module < Class < Object

Another possibility, would be getting rid of the class Module
altogether, by either relying on full-blown MI
or restricting the mixins to special "Module classes". Any of these
alternative schemes have their shortcomings,
but the current Class < Module < Object isn't flawless either.


/Christoph

 

[Christoph]

I'm not much into CLOS, but IIRC the basic approach is to linearize
the ancestors (not thinking of MOP, method combination and so on).
I can agree this yields similar result to our mixin strategy, but I
fail to see how it shows mixins are MI.

Linearizing a method lookup of ancestor (sort of) graph is
+ merging of ancestor graphs is the hall mark of MI to me.

It would at best show that CLOS' MI is similar to ruby's mixins.
If I would talk about how Eiffel or C++ handle the problem differently
would that prove my they MI!=mixins, or would show that CL has not MI
or simply that there are diferent approaches to the problem?

You snipped out (or I misquoted it) the part I was actually referring:


The core idea of MI (to me) is the ability to inherit two things that
would need to be instantiated, while using mixins this is impossible.

This sounds more like C++'s idea of MI (to me).

/Christoph

 

[David A. Black]

Hi --

The strongest argument against "meta Object" == Class are the current class
relations
Class < Module < Oject.
To resolve this we could subclass both Module and Class from Object directly,
or settle on relations
Module < Class < Object

I know there's this perhaps odd circularity, and singularity, at the
top of the model. But does it really need to be resolved? I've
always felt comfortable living with this as the price of bootstrapping
the rest of the model.


David

 

[Christoph]

I know there's this perhaps odd circularity, and singularity, at the
top of the model. But does it really need to be resolved? I've
always felt comfortable living with this as the price of bootstrapping
the rest of the model.

One way or another you need to sort of bootstrap any (alternative) object
model too. I also tend to agree that the case for resolving anything is not
all that strong, especially since I kind of like unresolved
singularities and
since they are probably unavoidable anyway (sort of like the singularity
marking the "beginning" of the time-space continuum).
My point (and Mathieu’s I believe) was that the validity of the average Ruby
script or even library would not be affected by some, even radical,
changes on the
top of the object model. Matz in fact changed the "method lookup path" of
”singleton classes" and especially "singleton singleton class" in the
past and I'll
bet hardly anybody noticed it.

/Christoph