[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ambiguity in defgeneric and method descriptions
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: ambiguity in defgeneric and method descriptions
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 5 Nov 87 22:48 EST
- In-reply-to: <871105-161832-1644@Xerox>
Date: 5 Nov 87 16:18 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
The alternative would be to follow the model of defclass; if
the old defclass defined readers or accessors and the new defclass
does not, during the redefinition those old methods and generic
functions go away. We could make old methods that were defined by
the :method option to defgeneric go away, if the new defgeneric
doesn't define those methods.
Whichever one is right, it's worth another Remark.
I agree that it's worth a Remark.
I think that it is important that old methods stay around. Consider two
applications that define a generic function. They are designed to work
independently, and also together. Hence each will have a defgeneric
(compatible of course, since they were meant to work together), and each
will independently define methods, say with their :method options. The
fact the the second one does not have the same methods as the first
should not invalidate the first, I think.
I have to agree with this argument, even though I feel that such a pair
of applications is poorly structured and should have a shared "definitions"
module that contains one defgeneric. Remember we're not forcing you to put
all your method definitions into :method options (except in generic-flet,
generic-labels, and generic-function).
The model I have is that
defgeneric updates the generic function with respect to its metaclass,
method class, etc. but does not affect existing methods.
Except it does affect existing methods if :method is specified, so this
argument isn't going to tell us anything about the case that Sonya
brought up. Instead we have to say: "Note, defgeneric can add methods,
and can replace methods, but never removes a method."
An error is
signalled for any compatibility problem of course. This is the same as
the old model. As you can see in some cases there are sources for the
other methods, and in others not (what happens now when you simply edit
a file to remove a defmethod or defun form?)
That depends on how smart your editor is. But surely if it understands
removing a defmethod it can understand removing a :method option from a
defgeneric.