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

[Alexandre Vasseur <avasseur@xxxxxxxxx>]

Hi

I think you need to define another designator than "call", since you
are using it as a type pattern ("the class that has some method ...").
"hasmethod" perhaps.

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.

Alex

On 7/11/05, Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx> wrote:
> I'm reworking my pet "Contract4J" project and I've discovered that
> support for some common Perl-like regular expression idioms in pointcuts
> would really help.  I would like to be able to write pointcuts that find
> a method or attribute "foo" and method "prefixFoo" (like the JavaBeans
> idiom for get/set), where foo is actually some sort of regular
> expression. For attributes, I would need something like
> 
> set (* \(*\).\(*\)) && call (* $2.prefix$3(..))
> 
> meaning "find all attempts to set an attribute in a class, save the
> attribute name in '$3' (the third group of escaped parentheses...) and
> the class name in '$2', but match join points only if there is a
> corresponding method in the same class '$2' named 'prefix$3'. (Actually,
> this doesn't convert the first letter of $3 to upper case, but ...).
> 
> I'm using escaped parentheses to distinguish between grouping constructs
> and method argument boundaries, etc. Note that something like
> 
> set (* *.*) && call (* *.prefix*(..))
> 
> would pick out sets of attributes in class "Foo" and methods like
> "Bar.prefixSomethingUnrelated(..)", which isn't helpful.
> 
> A similar expression for methods would be something like:
> 
> call (* \(*\).\(*\)(\(..\))) && call (* $2.prefix$3($4))
> 
> (Clearly there are legibility issues with the parentheses...)
> 
> Of course, the workaround is to match a larger set of join points, e.g.,
> just use
> 
> set (* *.*)
> 
> and to compute the information you need using reflection, etc. (I'm
> doing this now...) Efficiency becomes an issue, though. In general,
> being able to reason inline about the matched strings would be useful
> (especially at compile time) and it would make it easier to write
> reusable aspects while avoiding combinatorial explosions of advice and
> runtime overhead.
> 
> Does this make sense? If implemented, would it work with reasonable
> performance, etc. for potentially large programs?
> 
> 
> dean
> 
> --
> Dean Wampler, Ph.D.
> dean at aspectprogramming.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
> I want my tombstone to say:
>     Unknown Application Error in Dean Wampler.exe.
>     Application Terminated.
>     [Okay]    [Cancel]
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>