Re: [aspectj-dev] Regular expressions in pointcut expressions

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

Hi -

> @Pre ("n != null")
> public void setName (String n) { this.name = n; }
...
> So, I would like to write aspects that find these occurrances of  DbC 
> tests and their corresponding methods or fields and only advise the 

Would using the AspectJ 5 support for annotations in pointcuts work for you?

Wes


> ------------Original Message------------
> From: Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx>
> To: "Alexandre Vasseur" <avasseur@xxxxxxxxx>, "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
> Date: Mon, Jul-11-2005 8:54 AM
> Subject: Re: [aspectj-dev] Regular expressions in pointcut expressions
>
> 
> 
> Alexandre Vasseur wrote:
> 
> >...
> >Perhaps you can reformulate, since it sounds a very bad idea to write
> >something like "set(...) && call(...)" since obviously there won't be
> >any match for that as those are 2 different joinpoint kind.
> >
> >  
> >
> Right. I skipped over some details, but basically the intent is to 
> match 
> the 'set' join points where a corresponding method exists (or in 
> general, some corresponding condition is met). So, it would be more 
> like 
> this:
> 
> set (* \(*\).\(*\)) && if (exists (* $2.prefix$3(..)))
> 
> or something like that. Note that even without the regular expression 
> stuff, it would nice to have "exists":
> 
> set (private Foo.name) && if (exists (* Foo.prefixname(..)))
> 
> (Perhaps the "if" is redundant...)
> 
> Maybe it would also help to provide a few more details about why this 
> is 
> interesting for my Contract4J experiments. Currently, the tool has you 
> define "design by contract" (DbC) tests using expressions in strings 
> inside special-purpose annotations. E.g.,
> 
> @Pre ("n != null")
> public void setName (String n) { this.name = n; }
> 
> Which defines a "precondition" test that "it's illegal to call 
> setName() 
> with a null argument."  Currently, rather than embed a runtime 
> expression interpreter, a precompilation step is done (with Sun's APT - 
> 
> annotation processing tool) that generates aspects to implement the 
> tests. So, the string expression gets converted to code, which is then 
> compiled during the compilation step.
> 
> One approach to eliminating the precompilation is to introduce a 
> JavaBeans-like convention where DbC tests have the same signature as 
> the 
> methods they advise with a special prefix:
> 
> public void setName (String n) { this.name = n; }
> public boolean preSetName (String n) { return n != null; } 
> 
> For an attribute, I could define an invariant test that must always be 
> true after any change and before any read:
> 
> private String name;
> public boolean invarName () { return this.name != null; }
> 
> So, I would like to write aspects that find these occurrances of  DbC 
> tests and their corresponding methods or fields and only advise the 
> methods or fields with before, after, or around advice (as appropriate) 
> 
> to invoke the test methods.
> 
> dean
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>