Various Topics Discussed Last Week

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

    Date: Mon, 28 Sep 87 09:42:29 MST
    From: kempf%hplabsz@hplabs.HP.COM

    2) On blocks in methods:

    I agree that Alternative 1 would be best. Users who want something
    different can either use a :AROUND method, as Moon suggested, or 
    program their own generic function dispatching function, using
    the metaobject protocol.

Since we all seem to be agreed on this, I added the following to my
clos-decisions file, which can be used as a resource to make sure
we don't forget to document this decision:

2-34 Add to Remarks field: The body of (DEFMETHOD -name- ...) is surrounded
by an implicit block named -name-, if that is a symbol, or -name1-, if
-name- is (SETF -name1-), by analogy with DEFUN.  The same applies to
methods defined by the :METHOD option to DEFGENERIC, GENERIC-FLET,
GENERIC-LABELS, and WITH-ADDED-METHODS.  There is no implicit block around
the body of a method defined by the :METHOD option to GENERIC-FUNCTION.

Dissenters speak now.

    7) On NEXT-METHODS:

    The primary reason is for being able to tell if calling CALL-NEXT-METHOD
    would signal an error. I understand Masinter's concern, and wonder if
    perhaps it might not be better to handle this with Ken Pitman's error
    proposal. Other than finding out whether a call to CALL-NEXT-METHOD is
    valid, there isn't much use for the list of next methods, as Masinter
    has pointed out.

I have no real opinion on this, but we could change this to NEXT-METHOD,
which returns the method object that CALL-NEXT-METHOD would call if
there is one, and returns NIL if CALL-NEXT-METHOD would signal the
no-more-methods error.  Then we wouldn't have to worry about the
implications of consing, rplac'ing, and looking at the list.