[Openmcl-devel] mop issue

[rm at fabula.de]

On Sun, Oct 03, 2004 at 04:41:09AM -0600, Gary Byers wrote:
> 
> 
> On Sun, 3 Oct 2004, marco wrote:
> >
> > 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. 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.
> 
> The MOP's description of COMPUTE-CLASS-PRECEDENCE-LIST (AMOP p 173)
> says:
> 
> "All methods on this generic function must compute the class precedence
> list as a function of the ordered direct superclasses of the superclasses
> of CLASS.  The results are undefined if the rules used to compute the
> class precedence list depend on any other factors."

Ah, you had AMOP at hand, mine is at home :-)

> I read that to say that methods can change the ordering of the ordered
> direct superclasses, but can't (portably) introduce arbitrary classes
> into its result.
> 
> >
> > 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).
> 
> If my interpretation is correct - and the "results are undefined" -
> then working as you expect and complaining about inconsistency are
> both legitimate results.  I'm not sure offhand what the results would
> be if this interpretation is correct and the complaint was removed
> (i.e., whether other things expect the transitive direct-superclasses
> and the CPL to be directly related.)

Well, the class redefinition protocol most likely will break since 
the system doesn't "know" about the super-subclass relationship.
So, in Marco's example, if 'super' gets modified (say, a slot gets added)
none of the kclass instances will get updated and the system has a dangerous
inconsistency.

> [I haven't tried too hard to decode CCL::COMPUTE-CPL; I'm assuming
> that the "inconsistency" it's complaining about is that a superclass
> has a class on its CPL that isn't a transitive superclass of that
> class.  It's be nice if CCL::COMPUTE-CCL was a little more willing/able
> to describe the inconsistency it's complaining about ...]


Thanks, RalfD
> 
> 
> >  -- -Marco
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel