[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why can't DEFMETHOD talk to FORWARD-REFERENCED classes?
- To: firstname.lastname@example.org
- Subject: Why can't DEFMETHOD talk to FORWARD-REFERENCED classes?
- From: Jon L White <email@example.com>
- Date: Fri, 25 May 90 10:09:07 PDT
Can anyone justify the restriction in 88-002R, p.2-24, that
requires "A class must be defined before it can be used as a
parameter specializer in a DEFMETHOD form"?
Several questions have cropped up in the Lucid user community:
(1) What does "defined" mean? does it mean fully-defined such
that an instance can be made? [see the preceeding restriction
for MAKE-INSTANCE, on p.2-24] Or, could it be "defined" as
simply being some forward-referenced class [i.e., no DEFCLASS
has ever been done for it, but it was mentioned in the super-
classes list of some other defined class]
(2) When is a class considered to be "used" in a DEFMETHOD form?
Super-eagerly, at the time of macroexpansion of the DEFMETHOD
form? Or, eagerly, at the time of evaluation of the DEFMETHOD
form? Or, lazyily, at the first invocation of the generic
function? Or, lazily, at the first invocation of that particular
(3) Is this restriction peculiar to DEFMETHOD, or should it apply
to ADD-METHOD also?
I'm tempted to think that this restriction was imposed before
WITH-SLOTS took its present form -- perhaps it was felt that it was
necessary to disambiguate between special-variable references and slot
"variable" references in method code, such as you might have to do in
SmallTalk or Flavors. But this is not the case in CLOS; and if this
is the only reason for such a restriction, then it is overly burdening
the user community.
Incidentally, if *any* reasoning about the slots structure of the
specialized class is behind this restriction, then the answer to
the first question above must be "fully-defined", since inherited
slots contribute to a class's slots structure.
-- JonL --