[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: specializer metaobjects
- To: firstname.lastname@example.org, Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Re: specializer metaobjects
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Mon, 5 Nov 1990 13:37:00 PST
- Cc: mop.PARC@xerox.com
- In-reply-to: <90Nov5.email@example.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
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.