[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
some questions on your chapter 2 comments
- To: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
- Subject: some questions on your chapter 2 comments
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 19 Jan 88 11:45 EST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: The message of 18 Jan 88 21:08 EST from Linda DeMichiel <LGD@SAIL.Stanford.EDU>
[Added back the rest of the mailing list for this question, which is
of general interest.]
Date: 18 Jan 88 1808 PST
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
In your comments on chapter 2 you mention:
2-29 first line: This says that removing a :method from a defgeneric and
re-evaluating the defgeneric does not remove the old method. While that's
a good default behavior, we should make sure not to rule out smart program
development environments that know better what is going on and remove the
old method in cases where the user thinks that's appropriate. In the Error
Terminology introduced in chapter 1, implementations should be free to
extend this. Redefinition is a program development environment issue, not
really a language issue, anyway.
This suggested change doesn't sound right to me. The problem is that
if this behavior on the part of defgeneric is extensible, programs
that rely on the "default" behavior from defgeneric won't be portable.
Or did you intend something else here?
Redefining a definition is a program development operation, not a programming
language operation. Portable programs, with the possible exception of portable
program development tools, wouldn't depend on what happens when a defgeneric is
It wouldn't bother me a bit if we changed the language to require all
implementations to remove methods that were created by a defgeneric, if
the defgeneric were re-evaluated without the :method. We already do this
for accessor methods created by defclass. We're now saying that the class
remembers the specific method objects and removes them if they are still
there; if they've already been replaced by a defmethod, it doesn't remove
the method put there by the defmethod.
What would bother me would be if we required all implementations to be
stupid about this.
So how about it? Shall we change CLOS so that re-evaluating a defgeneric
removes methods that were previously defined by :method, but no longer
appear in the new defgeneric form? I think we should.