Consider annotation composition

[Volodymyr Kushnir]

Hi there, always wandered if you guys considered such approach. And if yes - what are your thoughts on this.

Made very small PR to show what i mean:
https://gitlab.com/last-man-standing/lombok-fork/-/merge_requests/1/diffs?view=parallel

Thanks for feedback!
Volodymyr

[Marc Günther]

Hi Volodymyr,

I guess it would be very helpful for maintainers, who already have way too much work on their hands, if you could write a quick summary of what you actually want to accomplish? Like, why would I want such feature, and what do I gain from using it. "Consider annotation composition" doesn't tell me anything, and I'm certainly not missing it in my daily work.

But maybe that's just me, and it's completely obvious to everyone else.

Marc

[Volodymyr Kushnir]

Hi Marc,

Sorry I've added all my thoughts to the PR and forgot to provide details in email. If briefly:
-) each annotation has a corresponding handler, which has a well-defined interface but quite often when handler A re-uses handler B (where A and B are different lombok annotations). It uses its own slightly modified handler method version.
-) my suggestion is to introduce annotation coupling (via composition), so if annotation A uses annotation C this will be explicitly stated in annotation code (this is what i've tried to show in the PR). Adding such coupling will allow slightly modify handler interface to let the handler know it is handled as standalone or as part of another annotation.
-) potential benefits: this creates nice opportunities to re-use annotations (and thus their corresponding handlers). Example: assume annotation A is an existing lombok annotation which consists of B, C, D annotations (existing as well), its handler A will extract B, C, D parts and delegate calls to their corresponding handlers via public interface instead of some other annotation-specific methods. There is no much improvement window for annotation A, but if you will need to create some new annotations X or Y with composition any of B,C,D in them, handler code will be about single line calls (or smth like that).

Not sure if this explanation is good enough to describe PR. Also not sure PR has enough changes to show efforts needed and potential benefits. To summarize: idea is to simplify handlers re-usability which might give benefits in the long, long run.

Best Regards,
Volodymyr

пн, 26 вер. 2022 р. о 18:08 Marc Günther <yo...@schli.ch> пише:

--
You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/d4EKgdVMrJo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/7151a45d-6c2d-4613-acd5-875a216b6cdan%40googlegroups.com.

[Marc Günther]

Hi Volodymyr,

thanks for the detailed explanation. This sounds interesting, unfortunately this is way over my head, so I will leave the discussion to the more knowledgable people here. :)

Marc