Delegate deprecation

[Joe Castro]

First and foremost I want to say thank you for this project.  I've used it at a couple companies now and it's caught multiple bugs in the codebases and made things much more maintainable.

I was disappointed to see Delegate deprecated to experimental in a recent update.  I've found the feature to be useful.  When I've needed it the Lombok'd version of the code was still much cleaner than the alternative, despite that the API is relatively "unfriendly".

I just wanted to drop a note saying that (at least anecdotally) it is used, and vote for it to be brought back out of experimental status.

[l.p...@senat.fr]

+1

Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|

[Vyacheslav Blinov]

I just want to add that @Delegate is the feature of lombok, that became number one for me, becase it enables better code reuse for me (I use it like mixins for interface implementation).

18 июня 2014 г. 3:39 пользователь "l.p...@senat.fr" <l.p...@senat.fr> написал:

> --
> You received this message because you are subscribed to the Google Groups "Project Lombok" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Reinier Zwitserloot]

We're not going to kill it; it had always been experimental, so this is just a step to reflect that fact in the API (delegate predates the experimental package which is why it wasn't in there from the start).

[Ari G.]

Glad to hear you're not going to kill it.  I just wanted to jump in and upvote work on this feature by stressing that @Delegate is, IMHO, the single most useful feature of Lombok after @Data, @Getter, and @Setter.

[JWATERLOO]

Thank you again for this project.

Please don't get rid of @Delegate for all the same reasons listed; multiple inheritance, ie traits, ie. mixins, ie. multiple implementation inheritance. Please continue to enhance to give us control over diamond problem. Fine with removing some support if it means getting to keep something.

...

On a different note, is the any chance of lombok-ds being absorbed into your dragon experimental. Compile time binding ie. compile time reflection can greatly increase type safety.

[Robbert Jan Grootjans]

I think in general, if we look at integrating features in to 'lombok-core', that will be done if they are interesting enough, and just as important, stable. (see previous conversation on @Delegate). A few really great ideas of lombok-pg have already been integrated into lombok, so there is definitely precedence.

I for one think it's fine that lombok-ds is maintained by those that really know why it's adding value, and care about it's existence. Lombok could stand to have a better way at adding additional functions (plugins, or whatever), as the current alternative is to for the repo and add stuff. I think we shouldn't add more features to lombok (core) and focus on having our pie and eating it.

my 0.02 cents.

--

[Vyacheslav Blinov]

Just wanted to add that compile time error that happens with latest lombok version then you have nested delegates prevents me from upgrading :( Although I understand the driver behind this error, the code where I’m using it has good test coverage and thus, I’m aware of possible problems, if there are some. Is there a way to make this not an error, but at least warning? It’s good to still have it as reminder that this is something that is not well supported and considered to be corner case, but I want to decide on my own whenever I want to live with it or not.

Regards,
Vyacheslav Blinov
https://github.com/dant3

[Dirk Peters]

+1

I use @Delegate in many projects to extend final entities with functionality. Especially together with @RequiredArgsConstructor it generates some easy to read code.

eg.: Stream<User>.map(EnhancedUser::new).map(EnhancedUser::injectedMethodCall)

Which I find a lot better than either mapping it into a derived Entity (which costs performance) or having a AccessWrapper which would split the additional methods from the entity itself.