[Openmcl-devel] mop issue

[rm at fabula.de]

On Sun, Oct 03, 2004 at 11:37:30AM +0200, marco wrote:
> rm at fabula.de writes:
> 
> >> should _not_ since super is already a super class of foo which is a
> >> super class of bar. adding super to bar's direct-superclasses would
> >> probably work most of the time, but really isn't what i want.
> >
> > Why? If you append it to the list of direct-supers? Anyway, the way 
> > clsql does it: look if super is already on the cpl of any of the 
> > direct supers and append it to the list iff not.
> 
> simply because i don't want super to be on the list of
> direct-superclasses, i only want super to be on the c-p-l.

But what is the semantic of such an operation? The cpl provides a 
topological ordering of a class' superclasses. But in your usecase
'super' _isn't_ a superclass of 'bar' (since it's neither a direct
superclass of bar nor a direct superclass of any of foo's super-
classes) - that's where the inconsistency lies. Besides the cpl, 
super/subclasses are linked by means of their DIRECT-SUBCLASSES
and DIRECT-SUPERCLASSES slots. If you only splice 'super' into the
cpl class 'foo' these slots won't get updated by the Lisp implentation.
Err, the first time such an update would happen in your sample repl
is actually when you create class 'bar': the system has to update 
foo's subclass slot.  Iff you do what you do your system might end
up in a rather inconsistent state once you start to redefine classes:
you might end up with old instances that still have an older generation
of you class as a class metaobject ....

> let me rephrase the question: i'd like to write a metaclass which
> ensures that all instances of the metaclass have super on their
> c-p-l.

But _not_ somewhere in the chain of superclasses (either as a direct
superclass or as a superclass of a superclass) ?

> should the user of defclass not put super in the
> direct-superclasses, nor provide a direct-superclass which has super
> on it's c-p-l, i would like super to be the first element (after the
> class itself) of the c-p-l.

That's exactly what CLSQL (and (Un)CommonSQL) do.

> [...]
> 
> i can define SUPER (obviously), i can also define FOO and doing so i
> find SUPER on it's c-p-l whether or not i put super in foo's
> direct-superclass. the error only occurs when attempting to define BAR
> and it occurs in the call to call-next-method. so i'm doing something
> to foo's c-p-l which makes determinig bar's c-p-l using the standard
> implementation of c-c-p-l error. if however i manually insert super in
> foo's direct-superclass then the c-p-l of foo is equal to what it was
> before, but i'm able to create the bar class.

Well, that's what i detected too. And to me it makes sense ...
You manipulate an optimisation [1] - the cpl makes the ordering of
superclasses explicit. It _could_ be computed on the fly (but that
would be highly inefficient). You should manipulate the list of super-
classes (iff needed).

> on cmucl and sbcl this code works as i expect it to work, but maybe
> i'm just lucky (i haven't tried on other implementations).

I have the feeling that that _might_ be just luck :-)


HTH RalfD

P.S: this is just my personal view, i'm _not_ a MOP expert at all ...

[1] I guess that's not entirely true: the explicit cpl migh allow
a programmer to manipulate the _ordering_ of superclasses.


> 
> -- 
> -Marco
> Ring the bells that still can ring.
> Forget your perfect offering.
> There is a crack in everything.
> That's how the light gets in.
>      -Leonard Cohen