> On 18 May 2017, at 10:42, Didier Verna <[email protected]> wrote: > > zbyszek <[email protected]> wrote: > >> Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze: >>> >>> If you are defining the method combination, you have way more freedom >>> and flexibility than mere before and after. Basically, you can do it >>> yourself. >>> >> >> But Didier is asking about BUILT-IN method combinations. Possibly it >> was hard to define reasonable agreed semantics for before an after >> methods in the case of something like AND or APPEND (technical >> troubles aside). > > Right. I was merely curious. It's pretty obvious to me why you > wouldn't allow CALL-NEXT-METHOD in non-standard built-in combinations, > but I can't figure out why or how before and after methods could be > problematic, so I was wondering...
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators. Does that make any sense? Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
