[Openmcl-devel] [Re: MOP Question: structure of Lambda list for direct-slot-definition-class]

[Gary Byers]

On Mon, 21 Feb 2005 rm at fabula.de wrote:

> Hello OMCLers,
>
> i just forward this  to the list in case someone doesn't read c.l.lisp.
> BTW, anyone comming to Amsterdam in April?
>
>
>  cheers Ralf Mattes
>
> ----- Forwarded message from "R. Mattes" <rm at mh-freiburg.de> -----
>
> X-Original-To: rm at seid-online.de
> From: "R. Mattes" <rm at mh-freiburg.de>
> Subject: Re: MOP Question: structure of Lambda list for direct-slot-definition-class
> Newsgroups: comp.lang.lisp
> To: rm at seid-online.de
> X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.29.0.16; VDF: 6.29.0.140; host: forte)
>
> 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."

The handling of MAG-STEP in the example in Figure 5.2 (AMOP p148) tends
to confirm the interpretation that the values of non-standard slot
options should only be collected into a list if they're provided multiple
times.

Since there's no way of enforcing a requirement that non-standard slot
options appear at most once (as is enforced for things like :ALLOCATION
and :TYPE), the burden of checking for that (and of handling both
list-valued and atomic option values) falls on the initarg-handling
code that constructs the slot-definition object.

Consider code like:

(defmethod shared-initialize :after ((slotd foreign-direct-slot-definition)
                                     slot-names
                                     &key (foreign-type '(:id)))
  (declare (ignore slot-names))
  (if (and (consp foreign-type)
           (null (cdr foreign-type)))
    (setf (foreign-slot-definition-foreign-type slotd) (car foreign-type))
    (error "~S must be a 1-element list" foreign-type)))

which is based on the current (non-Figure-5.2-compliant) interpretation
(where the values of non-standard slot options are always collected into
lists.)  Note that it's a little awkward to enforce the restriction that
:FOREIGN-TYPE (like :TYPE) is provided at most once.  Note also that
it's possible to enforce that restriction.

(defclass class-using-foreign-slots (whatever)
  ((slot :foreign-type :foo :foreign-type :struct)))

(defclass class-using-foreign-slots (whatever)
  ((slot :foreign-type (:struct foo))))

Depending on the (unspecified) order in which multiple option values
are collected into lists, these forms might be equivalent under the
Figure 5.2 interpretation.

I'm not convinced that it provides the best way of handling that
problem, but Figure 5.2 convinces me that that's what the paragraph
quoted above is trying to say (e.g., that non-standard slot options
should not be treated consistently and resolving ambiguity - if
that's possible - should be left up to code that actually handles
the initargs.)

So yes (kicking and screaming), this should be changed (as should
any code like the SHARED-INITIALIZE method above) that depends on
current behavior.