[Openmcl-devel] MOP errors

[Dan Knapp]

> I'm trying to use the BKNR datastore in openmcl
> (http://bknr.net). When I try to load the datastore application, I get
> the following error message:

   Never heard of it.  Their site seems to be down at the moment.  I'd 
be interested to
learn more.
>
> Is this a problem with openmcl's incomplete implementation of the MOP,
> or should I look elsewhere?

   It looks to me like a MOP portability issue.  I don't know whether 
OpenMCL is still in the
lead on MOP compatibility, but it's got a quite complete implementation.

> | The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a
> | super-class of the class #<BKNR.DATASTORE:PERSISTENT-CLASS 
> BKNR.DATASTORE:STORE-OBJECT>;
> | but the meta-classes #<STANDARD-CLASS STANDARD-CLASS> and
> | #<STANDARD-CLASS BKNR.DATASTORE:PERSISTENT-CLASS> are incompatible.
> |    [Condition of type SIMPLE-ERROR]

   That error message is produced by the default method on 
VALIDATE-SUPERCLASS, and
what it appears to say is:  BKNR defines a metaclass PERSISTENT-CLASS, 
and a class
STORE-OBJECT which uses PERSISTENT-CLASS as its metaclass.  The 
definition of
STORE-OBJECT says that it inherits from STANDARD-OBJECT.  
STANDARD-OBJECT
uses STANDARD-CLASS as its metaclass.  VALIDATE-SUPERCLASS has not been 
told
that it's permissible for a PERSISTENT-CLASS to inherit from a 
STANDARD-CLASS.

   What the fix is depends upon whether it's really "okay" for 
STORE-OBJECT to inherit from
STANDARD-OBJECT.  If it is, then all that need be done is to define a 
new method on
VALIDATE-SUPERCLASS:

(defmethod validate-superclass
   ((class bknr.datastore:persistent-class) (superclass standard-class))
   (declare (ignore class superclass))
   t)

   But the fact that such a definition has not been provided proves that 
BKNR has not been
tested with OpenMCL, so there might be quirky behavior caused by subtle 
MOP differences.
There is not yet a complete standard for the MOP, and the book AMOP is 
confusing and
occasionally under-specifies things.  AMOP can't be blamed for that, 
since it's only recently
that MOPs have gotten heavy use, but ...  Anyway, proceed with caution: 
don't trust any
important data to this system until you know it's reliable.

   Hope this helps.

-- Dan Knapp