MOP questions (was Re: [Openmcl-devel] byte-strings)

Gary Byers gb at clozure.com
Tue Aug 31 00:58:37 PDT 2004



On Tue, 31 Aug 2004, Ben wrote:

> thanks for the help.
>
> now some MOP questions, relating to adding additional keywords to
> slots:
>
> 1) it appears that direct-slot-definition-class is receiving initargs
> sometimes inside of lists, e.g. like
>
> (:name slot3 :allocation :class :transient (nil))
>
> (transient is a slot keyword which we've added to our specialized
> slot-definition.)
>
> why is this? is it safe to assume this will always be the case?

It wasn't always the case, but I believe that this behavior is correct.
Builtin/standard slot options come in two flavors:

1) Things like :DOCUMENTATION, which can appear at most once and which
   has a single value associated with it.
2) Things like :INITARG, which can appear multiple times in the slot
   specificatiom and where the associated values are collected into
   a list.

DEFCLASS treats things that it doesn't know about like the second
case (or at least closer to it).  See the last bulleted paragraph
on page 148 (section 5.4.2) of the AMOP book, and the handling of
the LOCATOR slot option in the example in figure 5.2 on that page.

Prior to 0.14.2, OpenMCL's DEFCLASS treated unknown slot options
as being analogous to case (1).  This was incorrect.

>
> 2) i am having trouble using additional slot keywords, because
> effective-slot-definition-class isn't getting the keywords.  looking
> at the sources compute-effective-slot-definition, it is constructing
> an initarg plist that doesn't include my :transient key.  this is is
> contrary to my reading of the MOP "spec."
>

COMPUTE-EFFECTIVE-SLOT-DEFINITION gets a list of one or more
DIRECT-SLOT-DEFINITION objects as an argument; it analyzes the values
of various slots in these direct slot definitions, applies inheritance
rules, and constructs a set of initargs to pass to MAKE-INSTANCE
(and to EFFECTIVE-SLOT-DEFINITION-CLASS.)

The standard primary method for COMPUTE-EFFECTIVE-SLOT-DEFINITION has
no idea what extra slots your DIRECT-SLOT-DEFINITION objects contain,
and no idea of how the values of these extra slots should affect the
list of initargs used to both determine the effective slotd's class
and instantiate it.

It's unfortunate that COMPUTE-EFFECTIVE-SLOT-DEFINITION is defined to
both derive a set of initargs (to be passed to
EFFECTIVE-SLOT-DEFINITION-CLASS and then to MAKE-INSTANCE) and to pass
those initargs to those functions and return the result.  Some
implementations (PCL) split this up, and define a specializable
COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS method.  Without that
division of labor, the only real way of extending
COMPUTE-EFFECTIVE-SLOT-DEFINITION is to redo all of the standard stuff
in a specialized method and add code to handle your extended direct
slot definitions and determine the appropriate initargs.  The Cocoa
bridge does this.via an :AROUND method that reverts to the next method
if foreign slots aren't involved, but has to replicate much of the
primary method's work otherwise.





More information about the Openmcl-devel mailing list