Re: symbol-class is bad name

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

    Date: Wed, 4 May 88 16:24 PDT
    From: Gregor.pa@Xerox.COM

    After looking at everyone's comments, it seems like we should replace
    symbol-class with find-class.

Agreed (including your details, deleted from this reply).

find-class needs to take an optional environment (third argument) for
the same reason that symbol-class did (88-002 p.2-78).

    Date: Wed, 04 May 88 17:43:25 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    How about the following change too (for consistency):

    (GET-METHOD gf qualifiers specializers &optional errorp)

    ==>  (FIND-METHOD gf qualifiers specializers &optional errorp)

    (ADD-METHOD gf method)             and
    (REMOVE-METHOD gf method)

    ==>  (SETF (FIND-METHOD gf qualifiers specializers &optional errorp) 
	       method-or-nil)

I agree with this suggestion.

    Also, maybe ADD-METHOD and REMOVE-METHOD should persist for efficiency
    (since you may already have a handle on the method object) but be promoted
    to the meta-object level.  Then (SETF FIND-METHOD) should be defined in
    terms of them.

ADD-METHOD and REMOVE-METHOD should persist, but not for efficiency.
ADD-METHOD and REMOVE-METHOD are part of the anonymous-object layer,
whereas (SETF FIND-METHOD) is part of a layer for methods that is
analogous to the named-object layer for classes, generic functions,
and method combinations.  I say "analogous" because methods don't
exactly have names in the same way that classes do.