What is the idea behind wrapping before-methods and after-methods *of
all specificities* around the primary method call. Is it unusual to have
a method y, more specific than x, that doesn't need x's before-methods
or x's after-methods? (x and y have the same name of course)
Rick <······@yahoo.com> writes:
> What is the idea behind wrapping before-methods and after-methods
> *of all specificities* around the primary method call. Is it unusual
> to have a method y, more specific than x, that doesn't need x's
> before-methods or x's after-methods? (x and y have the same name of
> course)
You may want to read up on around-methods...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
In article <·················@yahoo.com>, Rick <······@yahoo.com> wrote:
> What is the idea behind wrapping before-methods and after-methods *of
> all specificities* around the primary method call. Is it unusual to have
> a method y, more specific than x, that doesn't need x's before-methods
> or x's after-methods? (x and y have the same name of course)
I don't think it is unusual. But then, you can put them into primary
method for X.
(defmethod foo ((x x))
(before-staff ...)
(call-next-method)
(after-staff ...))
or
(defmethod foo ((x x))
(before-staff ...)
(prog1
(call-next-method)
(after-staff ...)))
····@mac.mac.com (Takehiko Abe) wrote in message news:<·····················@solg4.keke.org>...
> In article <·················@yahoo.com>, Rick <······@yahoo.com> wrote:
>
> > What is the idea behind wrapping before-methods and after-methods *of
> > all specificities* around the primary method call. Is it unusual to have
> > a method y, more specific than x, that doesn't need x's before-methods
> > or x's after-methods? (x and y have the same name of course)
>
> I don't think it is unusual. But then, you can put them into primary
> method for X.
>
> (defmethod foo ((x x))
> (before-staff ...)
> (call-next-method)
> (after-staff ...))
This is not the same thing because there is no unique primary method.
It depends on the parameters.
;; primary method for widget
(defmethod foo ((w widget)) ...)
;; primary method for special-widget, derived from widget
(defmethod foo ((sw special-widget)) ...)
An auxiliary method FOO specialized to T will advise all primary
methods, even ones you haven't written yet.
Your explicit approach requires every primary method to be manually
instrumented.
In article <····························@posting.google.com>,
···@ashi.footprints.net (Kaz Kylheku) wrote:
> > > What is the idea behind wrapping before-methods and after-methods *of
> > > all specificities* around the primary method call. Is it unusual to have
> > > a method y, more specific than x, that doesn't need x's before-methods
> > > or x's after-methods? (x and y have the same name of course)
> >
> > I don't think it is unusual. But then, you can put them into primary
> > method for X.
> >
> > (defmethod foo ((x x))
> > (before-staff ...)
> > (call-next-method)
> > (after-staff ...))
>
> This is not the same thing
I thought the OP wanted a _different_ thing.
[I assume that you meant the above code is not the same as
using before/after methods. Am I missing something?]
Takehiko Abe wrote:
>
> In article <·················@yahoo.com>, Rick <······@yahoo.com> wrote:
>
> > What is the idea behind wrapping before-methods and after-methods *of
> > all specificities* around the primary method call. Is it unusual to have
> > a method y, more specific than x, that doesn't need x's before-methods
> > or x's after-methods? (x and y have the same name of course)
>
> I don't think it is unusual. But then, you can put them into primary
> method for X.
>
> (defmethod foo ((x x))
> (before-staff ...)
> (call-next-method)
> (after-staff ...))
>
This looks like what I want -- a way to have stuff happen before or
after the immediately less specific method without calling the before
and after methods for all less specific methods.
Rick wrote:
> Takehiko Abe wrote:
>
>>In article <·················@yahoo.com>, Rick <······@yahoo.com> wrote:
>>
>>
>>>What is the idea behind wrapping before-methods and after-methods *of
>>>all specificities* around the primary method call. Is it unusual to have
>>>a method y, more specific than x, that doesn't need x's before-methods
>>>or x's after-methods? (x and y have the same name of course)
>>
>>I don't think it is unusual. But then, you can put them into primary
>>method for X.
>>
>>(defmethod foo ((x x))
>> (before-staff ...)
>> (call-next-method)
>> (after-staff ...))
>>
>
>
> This looks like what I want -- a way to have stuff happen before or
> after the immediately less specific method without calling the before
> and after methods for all less specific methods.
By the time the above primary method runs any before methods will have
run, the call stack will show all around methods, and there will be no
way short of throw/signal/break to avoid the after methods running.
I do not think this is about CLOS. If you really need this, then the
Real Problem(tm) is that the stuff you have in the before/after methods
you are trying to avoid do not belong there at all. They belong in the
primary method with explicit logic (nicely self-documenting) which will
decide whether or not to perform said processing (and this miight mean
you need a new parameter to FOO to help with that decision.
(defmethod foo ((x x) situation)
(when (warranted-by situation)
(foo-before x))
(whatever x)
(when (sticky-p x situation)
(punt x))
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay