Barry Margolin wrote:
>>I would like to be able to call the next next-method in CLOS. That
>>is the method that would be called if the method invoked by
>>call-next-method called call-next-method. Is there any direct way to
>>do it?
>No, you're not supposed to have this much direct control. You can
>decide whether or not to call the next method, by putting a
>conditional around call-next-method, but it would be poor modularity
>to allow you to pick and choose methods to call. How do you know that
>some other class isn't going to get inserted into the hierarchy, so
>that the next-next method isn't the one you really intended to get?
But that objection holds for call-next-method too! In my case this
level of the class hierarchy is not meant to be public. Not that
excuses bad design, but in this case it might let me proceed quicker.
>>Another option seems to be to extend the standard-method-combination
>>with a + qualifier (using define-method-combination (long form)) that
>>would add all the results returned by applicable primary methods,
>I believe there's a built-in + method combination.
Couldn't find it in cltl2 or the hyperspec. However, the examples
under define-method-combination seem good enough to churn one out
quickly.
--shiv--
In article <··············@balrog.ece.ucsb.edu>,
Shiv <····@balrog.ece.ucsb.edu> wrote:
>
>Barry Margolin wrote:
>
>
>>>I would like to be able to call the next next-method in CLOS. That
>>>is the method that would be called if the method invoked by
>>>call-next-method called call-next-method. Is there any direct way to
>>>do it?
>
>>No, you're not supposed to have this much direct control. You can
>>decide whether or not to call the next method, by putting a
>>conditional around call-next-method, but it would be poor modularity
>>to allow you to pick and choose methods to call. How do you know that
>>some other class isn't going to get inserted into the hierarchy, so
>>that the next-next method isn't the one you really intended to get?
>
>But that objection holds for call-next-method too!
Not really. The idea is that a method can either augment the methods in
the superclass hierarchy (by doing stuff and calling call-next-method) or
completely override them (by not calling call-next-method). But when it's
augmenting them, it doesn't have to know what the rest of the hierarchy
does; they merely have to implement the contract of the GF.
>>I believe there's a built-in + method combination.
>
>Couldn't find it in cltl2 or the hyperspec. However, the examples
>under define-method-combination seem good enough to churn one out
>quickly.
CLTL2 section 28.1.7.4 Built-in Method Comination Types, paragraph 2, says:
"The names of the built-in method combination types are +, AND, APPEND,
LIST, MAX, MIN, MCONC, OR, PROGN, and STANDARD."
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Shiv <····@balrog.ece.ucsb.edu> writes:
> Barry Margolin wrote:
>
>
> >>I would like to be able to call the next next-method in CLOS. That
> >>is the method that would be called if the method invoked by
> >>call-next-method called call-next-method. Is there any direct way to
> >>do it?
>
> >No, you're not supposed to have this much direct control. You can
> >decide whether or not to call the next method, by putting a
> >conditional around call-next-method, but it would be poor modularity
> >to allow you to pick and choose methods to call. How do you know that
> >some other class isn't going to get inserted into the hierarchy, so
> >that the next-next method isn't the one you really intended to get?
>
> But that objection holds for call-next-method too!
No, it doesn't. Sorry, I was too hasty there.
--shiv--