Re: MAKE-METHOD arguments discussion

[Dussud%Jenner%ti-csl.csnet@RELAY.CS.NET]

	  From Moon:
	  Oh, gross!  What is the reason for wanting this?
      
      From Gregor:
      Let's not start this again.  I don't think this is gross.  In fact, I
      think it would be gross not to do it this way.  The point is, that with
      meta-objects, it is more natural than before for the user to write code
      which grovels around in the data-structure of the object system (the
      meta-objects).  In this kind of code, it is perfectly natural to want to
      invoke a method's function.
      

I think we must start this again. 
The real point is: How much of low level stuff do we want to expose?
The specification of the underlying metaclass protocol depends on the answer to
this question.
I think we want to expose enough so people can develop some new object oriented
paradigms without having to reimplement everything and being able to achieve some
compatibility between existing classes/metaclasses and their new ones.
But then we want to provide enough room for architecture specific optimizations.

Assuming that the function part of a method is funcallable outside of the context of
a generic function is a severe constraint. It limits seriously the amount of optimization 
we can do (like distributing the overhead between the generic function and the method 
function).
Furthermore, I don't think it is terribly useful for users to do this kind of thing. 
If it is, one would think that the CLOS is not too powerful since people have or want
to bypass the method selection mechanism provided by the system (i.e generic function call).

      From Gregor:

      I think it is bad modularity to push whatever slot access optimization
      implementations may want to do into the user's face, by tacking extra
      arguments onto method functions where the user can see them.
      Specifically, I think the way this is done in flavors (with
      self-mapping-table as the first argument) is bad modularity, because the
      user should be allowed to think that when they type:
      
      (defmethod foo ((arg0 class) arg1 arg2)
	(equal (si:all-args-to-this-function) (list arg0 arg1 arg2)))
      
      foo will return t.
      
      Of course this particular piece of code is not such a good example, and
      any example will not be portable, by my point remains valid --
      implementations should hide implementation details from the user.

Well, hiding implementation details from the user is the very reason why your
piece of code is not portable, Common Lisp never exposed the guts of a function.

There is a lot of implementation techniques out there for keyword arguments. For some
of them keyword arguments are not arguments but locals. So implementing actual function
with more or less "real" arguments is not something new.

My last point is: We will have some meta-object that the user can safely (portably) 
mess around with (using generic functions defined in the metaclass protocol chapter of CLOS)
and some that the user will notice but will not be able to mess with in a portable way.
This is true of any open system. Lisp programmers are used to it.

Patrick.