Re: [aspectj-dev] should undefined concrete pointcuts be an error?

["Ron Bodkin" <rbodkin@xxxxxxxxxxx>]

I think it would be fine to make this form an error, but would like if(true) and if(false) to be guaranteed to generate efficient code (e.g., cflow(if(false)) shouldn't cause a lot of work). I.e., if(false) should be just as efficient as call(* nonExistent()), and if(true) && otherpcd() should be just as efficient as otherpcd().

It might be worth providing standard library pointcuts for never() and always(), to provide greater readability.

Ron

Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895

> ------------Original Message-------------
> From: Ramnivas Laddad <ramnivas@xxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Tue, Aug-5-2003 12:10 PM
> Subject: 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):
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36431
> 
> 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
> match.
> 
> 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
>    kludgy.
> 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. 
> 
> -Ramnivas
> 
> --- 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
> http://sitebuilder.yahoo.com
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>