[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ambiguity in defgeneric and method descriptions



    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.