[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-dev] Restricting type from user defined pointcut
|
To say what you're trying to say now, I prefer your suggestion:
pointcut p(Foo foo) : ...;
before(Foo foo) : p(foo) && if(foo instanceof Bar) { ... }
because it's explicit and doesn't need to know how foo is bound
(and thus doesn't involve rewriting cflow, right?).
+ Another advantage of your proposal: to bind the subtype and avoid a downcast:
now:
before(Foo foo) : p(foo) && if(foo instanceof Bar) {
Bar bar = (Bar) foo;
...
}
under your proposal?:
before(Bar bar) : p(bar) { ... }
- There's no subtype requirement when binding on interfaces, so
the compiler could provide no warnings there in case of error.
- I'd feel more comfortable if the semantics of this(),
target(), and args() were exactly "instanceof"; exposing more
cases where something can be proveably of a certain type
but possibly null can make the semantics tricky. That's why
I prefer the clarity of the runtime if().
- I don't like that different clients of the "same" pointcut have
different semantics. I tried thinking of this in terms of parameterized types, but that hurt, too. I tried thinking about how tool support could show the clients of the pointcuts or show the explicit form.
So all-in-all, your proposal is attractive but not convincing
(to me). I imagine there are other more compelling opportunities
for syntactic sugar. I do think it's worth tracking as a bug,
so that when variable binding or this/target/args is revisited,
it can be a consideration.
Wes
> ------------Original Message------------
> From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> To: "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx>
> Date: Wed, Aug-31-2005 2:11 PM
> Subject: RE: [aspectj-dev] Restricting type from user defined pointcut
>
> As a follow up, the "hold your nose" version gets even worse in the
> case I'm
> dealing with, where the expression is bound in a cflow:
>
> ...
> public pointcut inRequest(RequestContext requestContext) :
> cflow(requestExecution(requestContext))
>
> //worse redundancy:
> public pointcut inDerivedRequest(DerivedRequestContext drc) :
> cflow(requestExecution(*) && this(drc));
>
> -----Original Message-----
> From: aspectj-dev-bounces@xxxxxxxxxxx
> [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Wednesday, August 31, 2005 2:01 PM
> To: 'AspectJ developer discussions'
> Subject: [aspectj-dev] Restricting type from user defined pointcut
>
> I would like to be able to test if a variable bound in a named pointcut
> is
> an instance of a subtype. For example, with
>
> public abstract aspect Base {
> public pointcut requestExecution(RequestContext requestContext) :
> execution(* RequestContext.execute(..)) &&
> this(requestContext);
> }
>
> I'd like to write a pointcut to say "a requestExecution where the bound
> variable is an instance of the subclass DerivedRequestContext." The
> "natural" thing to do fails:
>
> public pointcut derivedRequestExecution() :
> requestExecution(DerivedRequestContext);
>
> C:\devel\scratch\inner\Base.aj:9 [error] incompatible type, expected
> RequestContext found DerivedRequestContext
> requestExecution(DerivedRequestContext);
> ^^^^^^^^^^^^
>
> 1 error
>
> Now usually people faced with this situation will just hold their nose
> and
> write redundant code (which needs to be coupled to the details of how
> the
> used pointcut binds the variable):
>
> public pointcut derivedRequestExecution() :
> requestExecution(*) && this(DerivedRequestContext);
>
> It is actually possible to write a modular version of this with AspectJ
> pointcuts, but it's verbose and ugly:
>
> private pointcut derivedRequestExecutionParam(RequestContext
> requestContext) :
> requestExecution(requestContext) && if(requestContext
> instanceof
> DerivedRequestContext);
>
> public pointcut derivedRequestExecutionOk() :
> derivedRequestExecutionParam(*);
>
> In essence, I think it would be very useful if user defined pointcuts
> can
> filter on bound values just like the system defined pointcuts for this,
> target, and args. Is it too hard to implement this? Or do people think
> not
> allowing this is genuinely the right behavior? I find the asymmetry
> troubling, and the existing support for modularly doing this kludgely.
> Ramnivas reminded me that Adrian blogged about this a year ago to say
> essentially that this is the expected behavior (see
> http://www.aspectprogrammer.org/blogs/adrian/2004/05/effective_aspec.html).
>
>
>
> Appendix (complete code sample)
> public abstract aspect Base {
> public pointcut requestExecution(RequestContext requestContext) :
> execution(* RequestContext.execute(..)) &&
> this(requestContext);
>
> public pointcut derivedRequestExecution() :
> requestExecution(DerivedRequestContext);
>
> private pointcut derivedRequestExecutionParam(RequestContext
> requestContext) :
> requestExecution(requestContext) && if(requestContext
> instanceof
> DerivedRequestContext);
>
> public pointcut derivedRequestExecutionOk() :
> derivedRequestExecutionParam(*);
>
> }
>
> abstract class RequestContext {
> public abstract Object execute();
> }
>
> abstract class DerivedRequestContext extends RequestContext {
> }
>
> Ron Bodkin
> Chief Technology Officer
> New Aspects of Software
> w: (415) 824-4690
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>