[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Danny Bobrow <Bobrow.pa@XEROX.COM>
- Subject: Re: ---
- From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
- Date: 27-Jan-87 11:33:22
- Cc: common-lisp-object-system@SU-AI.ARPA
- In-reply-to: In-Reply-To: Msg of 26-Jan-87 14:58:00 from Danny Bobrow <Bobrow.pa@Xerox.COM>Msg of 26-Jan-87 14
Date: 26-Jan-87 14:58:00
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
2) There is no lambda-list. It also omits the keyword
:order from the method specifier. defgeneric-options is
extended to store parameters in the generic function. This
can be used to support features like reversed order for
<and> combination if desired.
There is a problem in tying up the parameters of the method
combination to the generic function. If the user has to access
those from the generic function, extensions where there can be
several method combinations defined for the same generic function
will not work. Parameters passed explicitly to the method
combination function avoid this problem.
In both versions of define-method-combination, the parameters passed are
a function of the particular generic-function.
That's true but david's one allows for extensions, yours does not. If
the mechanism that fetches the parameters is encapsulated, the
parameters don't have to be a function of the generic function only.
If the user has to get them explictly from the generic function slot, it
becomes apparent that they have to be a function of the particular
A generic-function can have only one method-combination type --
parametrized or not.
Well that's what is in the standard. I consider this assumption being
a simplification of a more general model. I understand that we don't
want to put the general model in the standard (Size, complexity.....)
but we can't lock the standard in a mode where only the simplistic model
can be supported without incompatibilities.
I am not sure that the :around keyword actually simplifies
things. It hides the around mechanism, but seeing the actual code
helps people to get the right model in their minds.
The point here is that we want to make it easy to suport :around
methods, and it is such a common idiom that we want to make it short.
By showing the translation (which people can understand once) we hope to
give people the right model in their minds.
I don't care that much about this point. Either way would be fine with
Despite these points, we seem to be converging on this issue.
I take this message as support for including this version of
define-method-combination as the one in the specification. I agree with
Gabriel that this committee should really amke up its mind.
You're jumping to conclusion. Convergence means that each additional
proposal has negligible added value.If we truly converge, we could leave
David's write-up because yours wouldn't bring much more. See, the
argument goes both ways!
More seriously, I think that David's proposal augmented with predicates
looks good to me, I would prefer it to yours for the reasons I brought