Re: New version of define-method-combination

[Gregor.pa@Xerox.COM]

Here are my comments about Danny's proposed changes to method
combination.  Some of these comments actually apply to Moon's last
revision also.  Basically, I am commenting on the contents of Danny's
message as a whole without being too careful about where the particular
ideas came from.

I agree with the elimination of the simple form of
define-method-combination.  I think this is a positive step towards
streamlining this part of the proposal.


I am not sure that method-group-specifier options are really needed.  In
my most streamlining mood, I would suggest removing them.  In a less
streamlining mood, I like the new :required method-group-specifier
option.

I like the new :around method-combination option.  I think this will
make it easier for people to deal with :around methods.  We might want
to think about changing the "sense" of this option, or changing the
default, so that aroundification happens by default.

I understand the motivation for allowing a predicate instead of the
templates.  I think that motivation should be presented explicitly since
without it, the predicate seems like uneeded complexity.

I like changing the name of the :around keyword to make-method-call to
:call-next-method.

I don't really like the fact that information is communicated to
make-method-call using special variables.  I thought having
make-method-call be a lexically bound function was much more elegant,
and much more in keeping with the lexically scoped way of doing things.

I don't really like method-combination-error and invalid-method-error.
They just add complexity to this part of the proposal to make up for the
fact that the error system has not been adopted yet.  There are many
parts of the object system which want to signal special kinds of errors,
we don't have special functions for all of them.  Perhaps what we should
do is assume the error system is going to be accepted (seems likely),
and then talk about what kind of error is signalled by each part of the
object system.  This seems more reasonable than introducing a bunch of
error functions which will just have to be removed when the error
proposal is adopted, or worse yet supported as backwards compatibility
for life.


I still don't like calling the default kind of method combination
standard.  I would prefer if we called it default, in fact, it might be
better to call it daemon-with-around or some other descriptive name.

What method combination types will we say are defined?  There is a
definite package problem here.  We should probably include some comment
on it in the spec.  A user can't very well go and do
define-method-combination of lisp:and.  If they do it "differently" they
could break the system or some other application.  I think the examples
should be re-worked to show users defining method-combinations whose
names are symbols which are not in the lisp package.