[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ---

   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
generic-function only.

  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