[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Various Topics Discussed Last Week
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Various Topics Discussed Last Week
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 28 Sep 87 17:05 EDT
- In-reply-to: <16906.559842149@hplabsz>
Date: Mon, 28 Sep 87 09:42:29 MST
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.