[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] should undefined concrete pointcuts be an error?

Want to point to an additional bug report (that made
me realize this usage of pointcut):


In 1.0 days, I used "if(false)" and that worked fine.
In 1.1, until I knew of this new way to define pointcut, I
used something like:

pointcut defineMePlease() : call(* methodThatMatchesNone())
                            && if(false);

The use of "&& if(false)" ensured that just in case, someone
has methodThatMatchesNone(), the join point still wouldn't

Two problems in using "methodThatMatchesNone()":
1. It is hard to explain. I remember trying to write text
   to explain this idiom. It was hard to avoid it sounding
2. Xlint gave warning (I think) that there is no such
   method as methodThatMatchesNone(). Sure, there isn't!

I do think we need some language support to define blank
pointcut. It should match the simplicity of a method with 
no implementation and it should not look kludgy.

While it will be more of an idiom (instead of language 
support) if(false) is a choice, if it can work in case of
around() advice. It is easy to explain, but I am not sure 
of any compiler issues. 


--- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> This idiom is new to me and works, but seems bad:
>     pointcut matchesNothing();
> Just today I've seen it used twice:
> - in Ram's book "AspectJ in Action" page 281
> - in Ron's bug
>    https://bugs.eclipse.org/bugs/show_bug.cgi?id=41124
> It seems bad to me because it's very close to another legal
> program with almost the opposite meaning:
>     abstract pointcut defineMePlease();
> The result of this mistake is not detected until runtime,
> so it's a costly one.
> I know of no other analogous case where an omitted definition
> resolves to a negative one. It's like defining the method
>     static boolean importantTest();
> as
>     static boolean importantTest() { return false; }
> When the quick reference defines the general form
> for named pointcuts, it instead requires a pointcut
> for non-abstract pointcuts:
>    abstract [Modifiers] pointcut Id ( Formals )  ;
>    [Modifiers] pointcut Id ( Formals ) : Pointcut ;
> So, I believe the compiler should emit an error when a
> concrete pointcut is not defined.  To actually say
> the first thing, one can do so explicitly:
>     pointcut matchesNothing() :
>          call(IOException thisPointcutMatchesNothing());
> or, if the compiler should staticly evaluate if():
>     pointcut matchesNothing() : if(false);
> Making it an error might also make it easier to write
> parsers for AspectJ.
> On the other hand, this idiom works in both 1.0 and 1.1,
> and there might be AspectJ programs in the wild that
> use it.  I hate to break programs, but I also hate to
> be bug-compatible and support valid but broken programs.
> So we should write an XLint message for this.
> The default level would be error if we agree it is an error
> and warning otherwise.  If it's an error, the message text
> can say this form will not be permitted in AspectJ 1.2,
> but users can disable the error until then in order
> to avoid having to rewrite their code.
> So:
> - is this idiom is an error?
> - objections to adding an XLint message in any case?
>    - is this message required for 1.1.1?
>    - does anyone care to offer guidance on writing
>      the XLint test?
> Wes
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software