Re: specializer metaobjects

[Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>]

    Date: Mon, 5 Nov 1990 14:25 EST
    From:	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.

That's a good reason.  It should be worded something like "If X is EQL
to Y, then (SPECIALIZER-INTERN X) is EQL to (SPECIALIZER-INTERN Y)" so
that X's value can be GC'd if there are no user-visible pointers to it.

It's just as easy to say it's the method's duty to remember what the
source of the specializers looked like in those implementations that
support such things.

       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.

It was just too early in the morning.

       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.

That sounds like a good place for it.