Re: specializer metaobjects

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

   Date: 	Mon, 5 Nov 1990 07:39:00 PST
   From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>

   Is there any reason for this other than to conserve space?  

Yes.  Without this concept of `interning', SPECIALIZER-DIRECT-METHODS is
a shaky concept.

   You call yourself an MOP programmer?!  There should be a specializer
   class, with subclasses class-specializer and eql-specializer.
   Specializer takes an initarg :SPECIALIZER-FORM.  Class-specializer
   also takes :CLASS and eql-specializer takes :OBJECT (or or some
   better name).

Hugh?  This just seems like another instance of the oldest OOP question
in the world.  Mixin or delegate.  Should a class specializer be an
object that points to a class or should it be an object which is a
class.  I chose the latter because it seems more elegant to me, and
because the former is a significant change from the current MOP.

   I'd like to see a parse-specializer generic function (two arguments, the
   form and the environment) and a parse-cons-specializer, three arguments,
   the car of the form, the cdr of the form, and the environment.  I'm not
   sure if the environment is really needed; better safe than sorry.  CLOS
   would come with two methods for parse-specializer, one specialized on
   symbol and one on cons.  parse-cons-specializer would have one method,
   eql-specialized on EQL.  Our CLIM would also add one eql-specialized on
   CLASS which provides an alternative syntax for a class specializer.

I would rather defer this to a full-fledged proposal for extensible
processing of the UI macros.