[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Various Decisions
- To: Common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: Various Decisions
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 29 Sep 87 15:23 EDT
- In-reply-to: <870929-104035-2118@Xerox>
Date: 29 Sep 87 10:40 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
On NEXT-METHODS, I prefer NEXT-METHOD to avoid the potential
confusion that RPLACD might cause for users.
I don't care. Remember that NEXT-METHODS was introduced first as an
improvement over call-next-method-or-nil. Hence its primary purpose was
to allow a programmer to avoid using call-next-method when it would
signal an error. NEXT-METHOD satisfies that goal. Question: Is there
anything else we want to make available at run time? If we are only
getting the next method, perhaps we ought to only have
NEXT-METHOD-P
which returns T or NIL; this might allow some optimizations of the
combined code.
Okay, here's what I have written down about this topic now:
The function NEXT-METHODS was added in September. It is scoped the same as
CALL-NEXT-METHOD, takes no arguments, and returns a list of method objects,
of which the first is the one that CALL-NEXT-METHOD calls. The effect of
modifying the list is undefined.
Moon and Gabriel like NEXT-METHOD better; it returns a method object or NIL.
Kempf likes NEXT-METHOD better than NEXT-METHODS, but likes nothing even
better, since CALL-NEXT-METHOD could signal a condition.
Bobrow: NEXT-METHOD-P, returning no unnecessary information, is even better.
Moon: I like that.