Re: indefinite extent of call-next-method

[kempf%hplabsz@hplabs.HP.COM]

> I don't find Jim's argument convincing at all.  To my mind,
> call-next-method is a function that is closed over the identity
> of the next method and the arguments to be passed to it, just
> as a function defined by labels with a free reference that is
> captured in an outer scope is closed over the variable in the
> free reference.  In both cases it's equally true and equally
> irrelevant to the scope of the closure that the value of the
> closed-over variable is only known at run time.

The difference is that the name of the free reference in the case of a function
defined by LABELS or FLET is lexically apparent, while the identity
of the next method and arguments to be passed for CALL-NEXT-METHOD are not. 
This means that a programmer trying to understand program structure for a
function defined by labels or FLET need only look at the source where the 
function is passed out of scope, while, with CALL-NEXT-METHOD, the programmer 
must run the code. In the case of the function, the values are dynamically
determined but the control structure is not, modulo function valued variables.
In the case of CALL-NEXT-METHOD, the control structure is dynamically 
determined. Anticipating the question of "how does this differ from generic
functions or a direct call to CALL-NEXT-METHOD", in both these cases there
are lexical cues that control structure is dynamically calculated. In the
case of a generic function invocation, it is the name of the generic
function, for which the application of SYMBOL-FUNCTION will return a
generic function object. In the case of CALL-NEXT-METHOD, it is the lexical
context of a method definition. An executable entity enclosing a 
CALL-NEXT-METHOD passed out of scope could be any one of a number of
things, some of which will give no clue that they enclose a CALL-NEXT-METHOD.

I understand your and Pavel's concern, however, I have a couple of problems
with this. I think it is important that the implications of making
CALL-NEXT-METHOD indefinite in extent be outlined up front, rather than
having implementors duplicate the discussion we've been going through.
This has been the case for other new concepts we've introduced, such as
generic functions. The other problem is one of design philosophy, which
is, of course, open to debate. I believe that it is usually a good idea
to offer people an "economy" option and a "luxury" option. Although
it's always dangerous to say what "most" people do, I think most
programmers won't be affected if CALL-NEXT-METHOD is implemented either
way. On the other hand, I can imagine certain "economy" CL implementations
in which implementing CALL-NEXT-METHOD as having indefinite extend may
be difficult, or adversely impact use of CALL-NEXT-METHOD in some manner.
Thus Dick's solution of specifying dynamic extent (as the "economy" option)
with "indefinite" as an allowable extention (as the "luxury" option)
appeals to me.

		jak