CALL-NEXT-METHOD and funcall-qua/send-as

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

re:  . . .   In that old class system, and in all versions
    of Flavors I am aware of, the body of a method can do things that the
    body of a function can't, such as reference instance variables, which is
    the argument for having a special way to name subroutines of methods
    that is different from DEFUN.  

An explicit goal of the EXTEND system was to unify the functional programming
syntax with a smalltalk like class system; indeed, the early versions of
the Lisp Machine CLASS system (and even FLAVORS) were so much like smalltalk
that they perpetuated the special metavariable status of 'self' (and 'super'
too, I think?) and thus didn't look like functions.  [Instance variables
were referenced with normal macros, since pdp10 Maclisp didn't support
"symbol macros"].

CLOS follows the EXTEND lead here.

As to how this relates to the funcall-qua/send-as issue -- the motivating
problem was really ease of implementing "delagation".  This is probably best
not handled as a kludge on CALL-NEXT-METHOD; however, maybe some thought
out to be given to this area in the concepts section of the spec? 

On the other hand, you seem to be concerned about the more general problem of
code-sharing in your comment:
    the problem [with SEND-AS] is that it is a way to name a function that
    is different from the normal way to name functions.  Instead of SEND-AS,
    I prefer to say that if two methods have a subroutine in common, that
    subroutine should be given a name with DEFUN in the normal way and then
    they both should call it.  . . . 
I don't think this is releated to "delegation".  Do you?


-- JonL --