I'm currently trying to make my MOP-using application more portable
(current implementation is SBCL). My code basically creates a new
metaclass whose slots have special initargs. My metaclass can have both
standard slots and "special" slots. I specialize both
direct-slot-definition-class and effective-slot-definition-class (both will either
create a special slot definition or pass control to the next method depending on the
presence of a special initarg). while rewriting the core using Marco Baringer's
MOP-abstraction seems to work OpenMCL breaks my application by _not_ generating special
slots at all. After closer examination it looks as if OpenMCL calls
direct-slot-definition-class like this (my crude printf-debugging):
Warning: Initarg for class #<RSLOT-METACLASS AUTHOR> is
(NAME BOOKS READERS (BOOKS-OF) WRITERS ((SETF BOOKS-OF))
ROLE (SUBJECT) VERB (AUTHORED) RELATION (BOOK) DB-KIND (RSLOT))
while i would expect (as SBCL indeed does):
WARNING:
Initarg for class #<RSLOT-METACLASS AUTHOR> is (NAME BOOKS
READERS
(BOOKS-OF)
WRITERS
((SETF BOOKS-OF))
INITARGS
NIL
ROLE
SUBJECT
VERB
AUTHORED
RELATION
BOOK
DB-KIND
RSLOT)
OpenMCL wraps all values given to keyword args into lists while SBCL just passes
the "raw" values. So, what's the correct structure of the lambda list? Is this under-
specified in AMOP (my copy is far away at home :-/
TIA Ralf Mattes
From: Bruno Haible
Subject: Re: MOP Question: structure of Lambda list for direct-slot-definition-class
Date:
Message-ID: <cvd5t5$aof$1@laposte.ilog.fr>
R. Mattes wrote:
> After closer examination it looks as if OpenMCL calls
> direct-slot-definition-class like this
You didn't say whether you create your classes through DEFCLASS or
ENSURE-CLASS. If you're using DEFCLASS, then the MOP says how slot
options should be handled (http://www.lisp.org/mop/concepts.html):
"All other slot options appear as the values of properties with the
same name as the slot option. Note that this includes not only the
remaining standard slot options (:allocation and :type), but also
any other options and values appearing in the slot specification. If
one of these slot options appears more than once, the value of the
property will be a list of the specified values."
> OpenMCL wraps all values given to keyword args into lists
> while SBCL just passes the "raw" values.
SBCL is right. The values should be wrapped in lists only when more
than one value is specified in the DEFCLASS form.
Bruno
On Mon, 21 Feb 2005 17:31:17 +0000, Bruno Haible wrote:
> R. Mattes wrote:
>> After closer examination it looks as if OpenMCL calls
>> direct-slot-definition-class like this
>
> You didn't say whether you create your classes through DEFCLASS or
> ENSURE-CLASS.
Ah, sorry, i forgot that part. Yes, i do create my classes with defclass [1].
> If you're using DEFCLASS, then the MOP says how slot
> options should be handled (http://www.lisp.org/mop/concepts.html):
>
> "All other slot options appear as the values of properties with the
> same name as the slot option. Note that this includes not only the
> remaining standard slot options (:allocation and :type), but also
> any other options and values appearing in the slot specification. If
> one of these slot options appears more than once, the value of the
> property will be a list of the specified values."
>
>> OpenMCL wraps all values given to keyword args into lists
>> while SBCL just passes the "raw" values.
>
> SBCL is right. The values should be wrapped in lists only when more
> than one value is specified in the DEFCLASS form.
Ok, i'll report this to the OpenMCL developers. BTW, maybe this should be
tested in the Closer test suite ...
Thanks a lot
RalfD
> Bruno
From: Pascal Costanza
Subject: Re: MOP Question: structure of Lambda list for direct-slot-definition-class
Date:
Message-ID: <cvevsa$4pq$1@snic.vub.ac.be>
R. Mattes wrote:
>>>OpenMCL wraps all values given to keyword args into lists
>>>while SBCL just passes the "raw" values.
>>
>>SBCL is right. The values should be wrapped in lists only when more
>>than one value is specified in the DEFCLASS form.
>
> Ok, i'll report this to the OpenMCL developers. BTW, maybe this should be
> tested in the Closer test suite ...
I have pushed it onto my todo stack.
Pascal