[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ---
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: ---
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 28 Jan 87 00:14 EST
- In-reply-to: <870127-182340-6111@Xerox>
Date: 27 Jan 87 18:23 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
The issue is whether that information is extracted by
the system and made an argument of the method, or extracted in
the method. I have suggested that extracting it in the method
is the general way to do it.
That is not really what you have suggested. You suggested
extracting it in the define-method-combination.
I suggest doing it in both. That is, any information other than the
combination-type (e.g. standard , and) which selects a method is
extracted from the generic function.
Your suggestion would mean that define-method-combination forms
would not be portable between systems that have only one method
combination type per generic-function and systems that are more
general. What I think Patrick is suggesting is that the extension
to allow more general selection of a method-combination type should
be orthogonal to the method-combination types themselves.
I don't understand how a generic function can have more than one
method-combination type.
It would be an upward-compatible extension to the standard. One way to do
it was proposed by Patrick in his message of 31 October. Another way, which
unfortunately only works for classical methods, exists in Flavors now.
I also don't understand your last sentence at all.
I hope Patrick's latest message clarified it. I was guessing at his
suggestion but he said it himself, about modularity and keeping the
various operations as independent as possible.
- References:
- Re: ---
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>