[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Moon's comments on Draft 11
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Moon's comments on Draft 11
- From: Jon L White <jonl@lucid.COM>
- Date: Thu, 1 Nov 1990 14:29:41 PST
- Cc: mop@arisia.Xerox.COM
- In-reply-to: "David A. Moon's message of Thu, 1 Nov 1990 10:49-0500 <19901101154941.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>"
re: One is to make
STANDARD-ACCESSOR-METHOD a direct subclass of METHOD instead of a direct
subclass of STANDARD-METHOD; the other is to make a new class that is a
direct superclass of both STANDARD-METHOD and STANDARD-ACCESSOR-METHOD.
I support the former because it's simpler and I can't see a reason for
the latter, but I would certainly accept the latter if there is a reason
for it, for example if there is common behavior between the default
method class used by DEFMETHOD and the default method class used by
DEFCLASS that should be captured on a common superclass. We can't make
Wait a minute -- isn't the default class used for DEFMETHOD the class
in GENERIC-FUNCTION-METHOD-CLASS? (and the default for the corresponding
argument to DEFGENERIC is STANDARD-METHOD class.) I liked Scott's idea
of having a way to say to DEFMETHOD that you want it to make a method
of a non-default class; Gregor seemd to support that too.
As to whether the method class for accessor methods should NOT be a
subclass of STANDARD-METHOD -- well, those accessor methods, as objects,
certainly share a awful lot with STANDARD-METHOD's, with only a delta's
worth of difference. That's the classic case for subclassing in order
to maximize code reusability.
Consider, for a moment, the task that an end user would have if he were
to define a new method class; it would be very hard for him to do it
without recourse to subclassing STANDARD-METHOD -- *almost* as hard as
it would be to correctly define a new metaclass that isn't a subclass
of STANDARD-CLASS. This isn't to say that it's a stumbling block for
implementors, but rather to point out the value of code and class
reusability. So I'd want to see very good semantic (or typological,
or theological) reason before giving up on the commonality.
-- JonL --