[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Making (CLASS-OF <class>) be EQ to <class>
- To: Jon L White <email@example.com>
- Subject: Making (CLASS-OF <class>) be EQ to <class>
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 28 Sep 1990 10:31-0400
- Cc: firstname.lastname@example.org
- In-reply-to: <9009280052.AA03245@caligula>
Date: Thu, 27 Sep 1990 20:52 EDT
From: Jon L White <email@example.com>
re: 1. When CHANGE-CLASS is applied to a class object, shouldn't it also
call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago
Perhaps. Doesn't it also need to check metaclass compatibility?
Hmmmmm, now that you mention it . . . I guess checking VALIDATE-SUPERCLASS
on the class-prototypes is ok?
I wouldn't know.
2. If there are methods defined on function FOO at classes respectively
<C1, C2 ...>, then how can one temporary override the effective
method at that point, and cause it to defer to the next most
This is just CALL-NEXT-METHOD, so you must mean something that I didn't
I don't think CALL-NEXT-METHOD does exactly that. For example,
CALL-NEXT-METHOD from within a single :AROUND method defined at the
point <C1, C2 ...> will invoke (probably) the primary method defined
at <C1, C2 ...>, rather than, say, the "effective" method defined for
point <C1, T ...>.
I may have misunderstood the semantics of SEND-AS, but that what I expected
it to mean -- "Treat this argument, for purposes of message/generic-function
dispatch, as if it's type were explicity FOOBAR rather than it's real type."
Now, I fully agree with you that replaceing Method Combination by simply
SEND-AS/LEXPR-SEND-AS is a loss; but an ocasional "exceptional" use of this
flavorized kludge might not be so bad.
As my first note mentioned, one is very tempted to use :AROUND methods and
CALL-NEXT-METHOD; but as Gregor indicated, CLOS just isn't one of "those"
kinds of language that make explicit delegation like this easy.
I think I might understand what you're getting at now.
Here's how I react to this sort of thing: The programmer has recognized that
a certain method provides some functionality that he would like to invoke, and
wants to have a name for that method and call it by its name. Well, Lisp
already has a way to name pieces of functionality and allow them to be called
by name, and I don't think we need to add another one. The invokable functionality
should have been made a function in its own right, and the body of the method
should have been a call to that function. In the more general case where it
was a set of methods that the programmer wanted to invoke, this functionality
should have been made a generic function in its own right, and the method for
one generic function should be a call to the other generic function.
The "problem" with what I say here is that the modularity has to be worked out
in advance. I wouldn't allow people to reach inside an existing program and,
without changing the source code of that program, pull out some functionality
that they want, but which was not packaged into a function by the author of
that program. Indeed, I wouldn't allow that. Years ago I had some experience
with object systems that worked that way and my conclusion was that it was a
bad idea. I think the author of the program has to decide what the modularity
is and what the protocols are, and the user of the program has to live with that
or else get the program changed "officially."