Re: add-method when method exists

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Summary of issues raised in this message:
1) Ambiguity in the documentation of add-method
2) General ambiguity in the language used in the spec
3) Should add-method become add-or-replace-method
4) Precisely when are errors signaled
5) Do we really want to make it an error to omit the primary method

    Date: Mon, 28 Dec 87 09:26:37 -0500
    From: kanderso@WILMA.BBN.COM

      Date: Wed, 23 Dec 87 13:04 PST
      From: Gregor.pa@XEROX.COM
  
      In the current version of the spec, if add-method is used to add a
      method to a generic function and there is already a method with the same
      specializers and qualifiers an error is signaled....
  
Actually the language in the version of the spec that I have is
ambiguous, and may not mean what you said.  It says (2-8) "If the given
method is already one of the methods on the generic function, as
determined by get-method, or if the method object is a method object of
another generic function, an error is signaled."  It's unclear to me
whether the first use of "method", without "object" appended, means
that "the given method" is the method actually passed as an argument
to add-method, or means that "the given method" is any method with the
same generic function, qualifiers, and specializers.  Whichever the
document means, it should say explicitly (1).  It could be trying to say
that add-method signals an error if the method is already attached to
any generic function, or it could be saying not only that but in addition
add-method signals an error if the generic function already has a
method with the same qualifiers and specializers.

Almost everywhere in the document that the word "object" appears as a
suffix, it is probably a signal of this type of ambiguity.  I think we
should eschew that phrasing if we can (2).

Effectively you're saying that add-method should become add-or-replace-method.
I have no objection to that change, and either name is okay with me. (3)

      I don't want to first remove the old method because if I do,
      the generic function will be in an illegal state (it will have no
      primary method).

    I agree that an error should not be signaled, but i don't see anything
    wrong with calling REMOVE-METHOD.
  
Page 1-31 says an error is signaled if there is no primary method,
but it doesn't say -when- the error is signaled (4).  Clearly the error can't
be signalled whenever there is a generic function in that state, since then
one could never create a new generic function.  Since the spec speaks of
applicable methods, perhaps it means the error is signaled only when the
generic function is actually called, in which case you have no real problem.
However, we probably want CLOS systems to be able to report this error
early when they can detect it, so users don't have to wait until they test
their program on all possible cases to realize they have violated this
restriction.  I think the spec is just extremely weak in this area, and
there isn't a simple fix, but I wanted to point it out, because depending
on how the spec is interpreted, the error you are worried about is not
actually signaled anyway.

    I see nothing illegl about a
    generic function without a primary method, and regularly define
    protocols that have no primary methods just :AFTER methods.

You may be using Flavors or Common Loops.  Flavors allows omitting the
primary method.  I forget whether Common Loops does too.  CLOS is
incompatible here.  I forget why it's incompatible, but it's easy to
get around it by defining a primary method with no specialized parameters
that does nothing. (5)