Re: [aspectj-users] Extend type patterns by qualifiers like public, inte

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I definitely do *not* hate you for saying this because still I have not contributed to improving the AspectJ documentation. I am thrilled that a feature already exists which I have been searching for. It is like free lunch, so thank you. :-)

While not having tested it extensively, it seems to work nicely AFAIK. I even found and answered a related question on StackOverflow, not without giving you credit for pointing me to the solution:
http://stackoverflow.com/a/25543865/1082681

Best regards
-- 
Alexander Kriegisch
http://scrum-master.de


Andy Clement schrieb am 28.08.2014 00:38:

> I know you will hate me for saying this :) Take a look in the read me for 1.6.9: https://eclipse.org/aspectj/doc/released/README-169.html
> 
> "Type category type patterns"
> 
> execution(* (!is(InnerType)).m(..)) {}
> !within(* && is(InnerType)) {}
> 
> Options for use in is() are: ClassType, AspectType, InterfaceType, InnerType, AnonymousType, EnumType.
> 
> I just had a look and there don't seem to be a mountain of test cases for it so you might have to try it in your code and see what happens, I'll certainly take a bug if it is misbehaving.
> 
> 
> On 27 August 2014 07:04, Alexander Kriegisch <alexander@xxxxxxxxxxxxxx <mailto:alexander@xxxxxxxxxxxxxx> > wrote:
>> Hi there (especially Andy Clement).
>> 
>> Before creating a Bugzilla ticket I wanted to get some developer feedback or hints to features I might have overlooked.
>> 
>> In type patterns (used as part of method signatures, in pertypewithing clauses or in declare parent statements) I generally miss the option to limit the pattern like this:
>> 
>> !interface com.foo..*
>> public enum foo.bar.Zot
>> 
>> For instance, I guess often it makes sense to exclude interfaces from ITD type patterns when declaring something like "implements Baz".
>> 
>> Is anything like this possible (I don't think so)? Planned? Generally a good idea with a chance of implementation? If so, should I create a ticket for it? I do not want to bloat the ticket list by something without a realistic chance of implementation.