Re: [aspectj-users] ITD for type patterns, not just exact types

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

Oh, so JDT is the problem, not the syntax and semantics extension as such. Actually I understand what you are saying, but your reasoning is mostly about the project's resource economics, namely your personal availability as you seem to be the sole maintainer presently. Have you ever thought of bringing someone else aboard to support you? I know that the up-front investment to get such a co-maintainer up to speed would probably be huge, but I imagine that there might be smart and interested developers out there somewhere. Remember my old offer to help you with mavenising the build? I guess there might other volunteers. I believe it is a question of the project's future to acquire more maintainers because currently the "truck factor" - how many devs need to be hit by a truck to bring the whole project to a grinding halt? - seems to be 1 (one). This sounds dangerous to me.

As for @DeclareMixin, I can se nothing new there in comparison to my native syntax approach. You might remember that I very much favour native syntax, even though it means more work for you with regard to (A)JDT. ;-) I would be sad to see it go away. I can add all kinds of stuff via "declare parents" or "@DeclareMixin", but all non-static. Even if my interface contains Java 8 static methods, they will not be declared in (as in compiled into) the mixin target class but remain on the interface. I.e., I cannot use it like "MyTargetClass.logger" but only by ways of "MyAspectMixinInterface.getLogger()", which would also mean that it is the very same logger instance for every mixin target class. Usually you want a different logger for each class in order to see its name logged during usage.

Regards
-- 
Alexander Kriegisch
https://scrum-master.de


Andrew Clement schrieb am 22.01.2019 03:58:

> I think there may be issues open for ITD on type patterns, I had a very quick
> look but couldn’t find them but it has been talked about before certainly.
> 
> I am wary of anything that makes ITDs more complicated as there are a few
> ‘hacks’ in JDT already to support them and I don’t really want to add any
> more. I even had a vague thought (don’t panic) about removing code style
> syntax and just using annotation style syntax (provided we had some form of
> feature parity - annotation style syntax isn’t complete enough yet for this).
> I’ve been thinking about it for a while but the new speed with which Java is
> moving is making the patching job something that has to be done more
> frequently, and it isn’t fun. This would leave all development time simply to
> improve the weaving and fix bugs there.
> 
>> But at least the type pattern syntax per se and the corresponding matching
>> rules already exist for normal (non-ITD) pointcuts, so maybe just the parser
>> needs to be extended and of course ITD generation itself (the process of
>> actually adding the same members, methods or constructors to a set of target
>> classes instead of a to single one) as well.
> 
> I’m really not sure what needs doing without digging into it, and I can’t
> honestly say when I’ll find time for that. But I recognize the power of the
> feature. How far can you get with a pattern on DeclareMixin?
> 
> Cheers,
> Andy
> 
>> On Jan 19, 2019, at 7:42 PM, Alexander Kriegisch <alexander@xxxxxxxxxxxxxx>
>> wrote:
>> 
>> Hi Andy.
>> 
>> Do you think there is a chance to implement a feature request about enabling
>> ITD for groups of classes instead of having to know exact class names
>> beforehand? A typical example is that people on StackOverflow often ask about
>> declaring static loggers via ITD. If this could be done in a more generic way
>> by utilising type name patterns instead of fixed type names, I think it would
>> be a huge and useful improvement. The only workaround thus far is to use
>> annotation processing, but then you also need to know beforehand which classes
>> to target because you need to annotate them. I personally try to avoid marker
>> annotations because I usually want to keep my core code as clean as possible
>> from AOP-related stuff, keeping the aspects really separate as cross-cutting
>> concerns.
>> 
>> I would be interested in your feedback before I just create a Bugzilla ticket
>> out of the blue, maybe without any chance for it to ever get implemented
>> because it would be too much effort to implement it in the first place. I am
>> aware of the fact the the AspectT syntax would need to be somewhat expanded
>> for this. But at least the type pattern syntax per se and the corresponding
>> matching rules already exist for normal (non-ITD) pointcuts, so maybe just the
>> parser needs to be extended and of course ITD generation itself (the process
>> of actually adding the same members, methods or constructors to a set of
>> target classes instead of a to single one) as well.
>> 
>> Kind regards
>> -- 
>> Alexander Kriegisch
>> https://scrum-master.de
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users