Re: Continuing comments on Draft 11

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

   Date: 	Thu, 1 Nov 1990 22:07:46 PST
   From: Jon L White <jonl@lucid.com>

   Right.  Andreas sent some out recently (to which email list? I can't 
   remember).  I have received some suggestions verbally from people who 
   wanted to add an option which basically said "do type-checking on stores 
   into this slot"; there's not much more to this except the need to
   be able to parse a user-specified option, and to store the result in
   a user-specified field of the slot-definition.  I vaguely remember
   something in one of the CLOS workshop papers also, but . . . 

The current MOP supports this level of slot option parsing.  What it
doesn't support is saying whether a given slot option should be
evaluated, efunctuated, collected into a list, or anything like that.
Right now, all it does it carry extra slot options over, unevaluated.

I like Scott's stuff, but I would rather see it written up as a paper
that would be an improvement to this MOP than trying to get it into this
MOP now.

   re: "STANDARD-" means the one that the user interface macros use by default.
       That is, what 88-002R says they do if you don't do any MOP stuff.

   Well that's an interesting view.  But you can change the default for
   DEFMETHOD by calling DEFGENERIC with a :method-class option, and that
   step alone isn't MOP'y.  It's entirely another matter to say that
   you can't create any other method class without MOP, or to say that
   none of the specified metaobjects other than STANDARD-METHOD and
   its subclasses will be suitable.

Yes, but logically :method-class, :generic-function-class and :metaclass
belong in the MOP.  Even though they are mentioned in 88-002R, 88-002R
doesn't by itself say enough about them that you could possible use them.

   How about this view: ``STANDARD means "concrete"; otherwise "abstract"'',
   with only a coule of exceptions (METHOD-COMBINATION and STRUCTURE-CLASS
   come to mind as exceptions, but they are also exceptions to the
   rule of ``"standard" means "default"'').

   Probably it's only a coincidence that all three views mostly coincide
   [the third being that ``"standard" means "slotted"''.]

Right.

   In an email discussion in the past, I recall discussing a fatal flaw 
   in the design of ENSURE-GENERIC-FUNCTION -- namely the :lambda-list
   argument doesn't carry enough information to be able to distinguish
   the dual purposes of (a) a target of macroexpansion for DEFMETHOD and 
   of (b) a target of macroexpansion for DEFGENERIC.  The current draft, 
   under the DEFMETHOD section "Processing Method Bodies" punts the issue 
   to ``The section "The Defgeneric Macro"''; but I can't find this section.
   Did I overlook it somewhere, or is this an intentionalp lacuna?

No, the DEFGENERIC macro needs to be written, but I was planning to do
it in the way we had decided to resolve this problem.

   There are six metaobject classes at or under SLOT-DEFINITION?  why?
   Implementationally, there isn't any need to make a class distinction
   between "direct" and "effective" -- this can be done by keeping
   separate lists.   

But, direct slot definitions have readers and writers whereas effective
slot definitions don't.  Also, effective slot definitions will have the
slot-definition--location stuff.  They really are different, and that
difference should be recognized in their classes.
		     
		     Admittedly, there is a need for a generic function
   that goes through the step of taking collected direct definitions
   and producing the effective definitions; but another class isn't needed.
   The alternative would have at most two classes.