[Openmcl-devel] mop issue

[Cyrus Harmon]

My guess is that you can't just drop a class onto the cpl as that isn't 
enough to make OpenMCL know that it is now one of its direct 
superclasses.

I did something similar sticking the superclass onto the 
:direct-superclasses in an around method in initialize-instance and 
reinitialize-instance. I used the clsql MOP stuff as a guiding example 
and that seemed to work pretty well.

Cyrus

On Oct 2, 2004, at 6:41 AM, marco wrote:

>
> i originally thought this was a miss understanding on my part, but
> sbcl and cmucl both deal with this code without a hitch.
>
> (in-package :common-lisp-user)
>
> (defclass kclass (standard-class)
>   ())
>
> (defmethod mopp:validate-superclass ((sub kclass) (super 
> standard-class))
>   t)
>
> (defclass super ()
>   ()
>   (:metaclass kclass))
>
> (defmethod mopp:compute-class-precedence-list ((class kclass))
>   (let ((cpl (call-next-method))
>         (super-cpl (mopp:class-precedence-list (find-class 'super))))
>     (if (member (find-class 'super) cpl)
>         cpl
>         (append (remove-if (lambda (class) (member class super-cpl)) 
> cpl)
>                 super-cpl))))
>
> (defclass foo ()
>   ()
>   (:metaclass kclass))
>
> (defclass bar (foo)
>   ()
>   (:metaclass kclass))
>
> when attempting to define the BAR class i get an "Inconsistent
> superclasses for #<KCLASS BAR>" error. i think the issue in in
> ccl::compute-cpl, but my understanding of the MOP (and in particular
> openmcl's implementation) is way to weak to figure out what's wrong.
>
> -- 
> -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
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel