Re: Mopping up after the fact

[Gregor Kiczales <gregor@parc.xerox.com>]

It seems to me that your proposal actually has two implicit parts.  The
first is that the protocol use to deal with effective slot definitions
metaobjects (and default initargs, but I won't talk about them
explicitly in this message), be enriched so that the implementation
could ask them about things like the kind of of initform they have
specially.  At least that is what I infer from the suggestion that there
would be "contant initform" and "eval initform" classes.  I agree that
this could and should be done, in a substantially more eleborate MOP.

The second part of your proposal is that the access protocol for getting
information from direct slot definition metaobjects be, essentially,
GETF rather than a set of generic functions.  You say that COMPUTE-SLOTS
is the only function that looks at these, so there is no need for them
to have the more sophisticated accessor protocol they have.

COMPUTE-SLOTS isn't the only function that looks at direct slot
definition metaobjects, any browser type of tool like the ones shown in
chapter two of the AMOP also have to look at these metaobjects.  But,
that is neither here nor there; if we were to document that GETF was
the way to access them, then any code could access them that way.

My concern is that I can think of examples where having the accessors to
direct slot definition metaobjects be generic functions lets me do
things I can't do if the accessor is GETF.  For example, in the
following code, I define a special kind of class, MY-CLASS; it has its
own special kind of direct slot definition metaobject MY-SLOT.  These
special direct slot definition metaobjects don't store the value of any
of the usual "fields" except name.  All the other fields have a special
default, unique to this class of class metaobject.

(defclass my-class (standard-class) ())

(defmethod direct-slot-definition-class ((class my-class) ignore)
  (find-class 'my-slot))


(defclass my-slot (direct-slot-definition)
     ((name :initarg :name :reader slot-definition-name)))

(defmethod slot-definition-type         ((s my-slot)) 'fixnum)
(defmethod slot-definition-initform     ((s my-slot)) '0)
(defmethod slot-definition-initfunction ((s my-slot)) #'(lambda () 0))
(defmethod slot-definition-initargs     ((s my-slot)) ())
(defmethod slot-definition-readers      ((s my-slot)) ())
(defmethod slot-definition-writers      ((s my-slot)) ())


This example is, perhaps, a bit contrived.  But I think it illustrates
the point that make the extensible OO protocol surrounding direct slot
definition metaobjects back into a non-extensible functional protocol is
troubling.  What I would rather do, actually, is change all the
metaobjects (direct and effective) associated with default initargs,
into real objects with a generic function based access protocol.  But
that will have to be for a fancier MOP.