[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: specializer metaobjects
- To: Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Re: specializer metaobjects
- From: Gregor Kiczales <gregor@parc.xerox.com>
- Date: Mon, 5 Nov 1990 11:25:35 PST
- Cc: mop.PARC@xerox.com
- Fake-sender: gregor@parc.xerox.com
- In-reply-to: "Scott Cyphers's message of Mon, 5 Nov 1990 07:39:00 PST <19901105153931.4.CYPHERS@SEAR.SCRC.Symbolics.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.