Re: bug in clsql MOP usage? -- change-MOP-class forbidden

Hoehle, Joerg-Cyril wrote:
> it seems a paradox that while CLISP announces its full MOP support,
> cl-sql does not fully work with CLISP because of MOP issues.

Actually, it's not surprising at all to me. Adding CLSQL MOP support
for each new lisp implementation (USQL ran only on CMUCL) has required
some adjustment in CLSQL to support that implementation's MOP. Thus,
the peppering of reader conditionals in metaclass.lisp, kmr-mop.lisp,
and package.lisp

> It seems that cl-sql is doing something forbidden by the MOP, which
> CLISP catches while currently supported implementations don't.

I don't recall. It's been a few years since I read AMOP, but in
general, I recall it being rather a underspecified document.

> sql/metaclasses.lisp has a call to CHANGE-CLASS

Yes, it does in compute-effective-slot-definition.

> Here's what Bruno Haible (author of CLISP's MOP) said on this issue:
> >Yes. There are four things that are not allowed with 
> >slot-definition objects:

Is he talking about "not allowed" with CLISP's MOP or is his referring
to statements in the AMOP book?  I don't have the AMOP handy (I loaned
it to a friend). But, in general, I don't see a good reason to change
something that works on Allegro, Lispworks, OpenMCL, CMUCL, SBCL, and
SCL. Rather, my goal is to add CLISP to that list.

> >  - Calling CHANGE-CLASS on them - explicitly forbidden,

Well, that's the issue at hand. I'm not sure if you reviewed the usage
of change-class, but change-class is used so that db-objects classes
can have direct superclasses which are not db-objects. The test suite
has an example fo that with the db-object class PERSON having a
superclass of THING is not a db-object.

CLSQL does this so that when the slots of an object are examined, the
code can assume each slot is an instance of
VIEW-CLASS-SLOT-DEFINITION-CLASS. Then, the results are computed from
examining the slots within the ESD rather than specializing behavior
based on the class of the slot.

> >The only way to influence the creation of slot-definitions is 
> >therefore to
> >use INITIALIZE-INSTANCE :AROUND methods on a particular subclass of
> >STANDARD-SLOT-DEFINITION.

The MOP is kinda fun because there is often more than one way to
achieve somthing. In this case, creating an :around method on
initialize-instance won't help. CLSQL's slot manipulation code depends
on those extra slots in the ESD.

> What would be a good way to resolve the issue?

I suppose it depends if Bruno's rule of change-class is actually a
rule from the AMOP or a rule for CLISP's MOP implemenation. If it is a
rule for AMOP, and not something that can not be easily worked around
in CLISP and CLSQL, then the CLSQL library could be modified to
examine the types of ESD objects rather than assume they are instances
of view-class-slot-definition-class.

> It would be worthwhile if a) cl-sql worked with CLISP and b) it
> contains correct (or portable) code (if it's broken).

I certainly agree with "a". As for b, I'm less interested in strict
AMOP compliance than having CLSQL work correctly on supported
platforms. As an example, Bruno's rule:

>  - Calling (SETF SLOT-DEFINTIION-xxx) on them - these setters are
>  - not specified by the MOP,

really breaks the whole CommonSQL API which overloads the :type slot
of an ESD to handle the SQL type. For example, ":type (string 30)"
tells CLSQL to create a SQL field type of CHAR(30) and a Lisp type
which can hold either a NIL or a string. So, a CommonSQL
implementation has to modify the type slot value to be (or null
string) rather than (string 30) for the application to work correctly.

Kevin