[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
short form of define-method-combination
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: short form of define-method-combination
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 18 Aug 87 18:22 EDT
I would like to propose a small simplification of the short form of
define-method-combination.
Recognizing both an unqualified method and a method whose qualifier is
the name of the method combination type as primary methods seems
unnecessary and confusing. It muddles the issue of the identity of
a method (these are two separate methods with separate identities,
yet they do the same thing).
In addition, the qualifier is the name of the method combination type
but in the keyword package, so this is one more place where CLOS is
inventing symbols that don't appear in the source of the program, and
each time we do that it seems to cause trouble.
A possible drawback of this simplification is that it might make it
harder for users to understand the difference between "primary method"
and "unqualified method", since there won't be a counterexample to
the theory that the two terms are synonymous.
The specific document amendments are as follows, referring to 87-002:
2-27 Remove "A method with the keyword symbol with the same name as
{\it name\/} as its one qualifier is also defined to be a primary
method. Attaching this qualifier to a primary method documents that
this method is intended for use with an unusual form of method
combination and can make programs easier to understand."
2-30 Remove ":and" after "defmethod func".
Remove "(:and)" after "primary ()".
2-31 Remove "(:and)" after "methods ()".
Remove "(:and)" after "primary ()" [two places].
A related point is that we forgot to say in the document that a primary
method is required when using a method combination type defined with
the short form of define-method-combination, just as when using standard
method combination. We should say that explicitly.