[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-dev] Restricting type from user defined pointcut
|
Hi Wes,
I agree with you that not having to downcast (thereby preserving
compile-time type checking) is an important advantage of my proposal.
Also, I thought that this(), target(), and args() were supposed to have
instanceof semantics. I did just file bug report 108894 for the discrepancy
from this with args, which I initially posted to aspectj-dev on July 18 (I'm
glad you reminded me!) Is there any case where they are not? Are there other
known discrepancies? This use case is all the more reason to be sure that
AspectJ binding forms always require an instanceof test.
I do think having more flexibility and power in variable binding in
pointcuts is an important future direction for AspectJ, but I wouldn't hold
up AspectJ 5 to get it!
I am not too troubled by the prospective ability to use an unrelated
interface, resulting in a runtime test, since that is consistent with what
is already available using this, target, and args.
When you say "I don't like that different clients of the 'same' pointcut
have different semantics...", I am not clear what you are saying. Is this
somehow different than the way that you can use the builtin pointcut
primitives to either bind or restrict types or both? How so?
I have filed bug report 108895 to track this topic: see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=108895
-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Wes Isberg
Sent: Saturday, September 03, 2005 4:45 AM
To: AspectJ developer discussions
Subject: 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
>
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
