Hi!
Could you please move ExtensionMethods out of Experimental section to the stable APIs? :)
It's a brilliant feature and will motivate IDE plugin developers to support it ASAP (i.e. https://github.com/mplushnikov/lombok-intellij-plugin/issues/21 )
Thanks!
My review of "Experimental because" section:
High-impact on code style
People got used to the extension methods thanks to Groovy, Kotlin, Scala and other alternative JVM languages.
Really would like to ship with utility methods to expand common classes, but so far lombok doesn't have a good distribution method for such runtime dependencies
Since Lombok is a syntax sugar library, IMO it's better to let other developers produce their libraries focused on this feature. There are many extension-ready libraries like Apache Commons as well.
Affects quite a bit of eclipse, and auto-complete e.d. do not work yet in netbeans
So far many Lombok features were supported after they made their way to non-experimental status. For instance, IDEA plugin is waiting for this feature to become non-experimental
Should @ExtensionMethod be legal on methods? Should it be legal on packages?
I definitely see scoped use-cases for it, if it's doable without huge implementation changes - IMO it's a good addition to the feature. Also, it will allow to gradually add them, on a per-method basis. At the same time, package annotation will help to use them in a code base where you have multiple classes in the same file. Both :+1: from me.
Agreed, it's a great feature and it works pretty well. I'd personally prefer to use it without any annotations, just configure the whole project to use one or more extending classes (as this helps to keep the style consistent). But that's a different story. I'm all for promoting @ExtensionMethod.
It's a great idea to move it out of experimental :)
Of the scopes of @ExtensionMethod discussed here the per-project scope is the most appealing to me because I would like to have project-wide extensions for Strings, Collections, Streams, Optional, and even for primitives.
@tlinkowski I was using Groovy where extension methods are global (well... I'm a committer actually :D ), I was using Kotlin where your have to import your extension method.
And I must say that import-based approach is better.
It's much easier to review such code, to avoid conflicts (you can select which method to use, in Groovy, for instance, it's classpath-dependent)
I don't mind if global extension methods will be supported later in Lombok, but right now I want them "as is" because global version is questionable, but current is strong and usable enough.
It's much easier to review such code, to avoid conflicts
@bsideup You're probably using tons of them. I'm much more conservative and use only a couple of them. This precludes conflicts and implies my desire for global definition. I guess that people more used to other JVM languages are less conservative and that we can agree on supporting both in the long run.
Hi @bsideup and @rzwitserloot! :) Is it still planned to mark ExtensionMethods as stable API?
Lombok does have support for package-based configurations using lombok.config so being able to specify extensions in this file (also being able to include other and exclude those) would make this feature less dangerous.
@rzwitserloot will this feature be promoted to stable status soon? It appears the IntelliJ lombok plugin authors are dragging their feet on implementing it because this feature is still in experimental status. mplushnikov/lombok-intellij-plugin#21
@rzwitserloot will this feature be promoted to stable status soon? It appears the IntelliJ lombok plugin authors are dragging their feet on implementing it because this feature is still in experimental status. mplushnikov/lombok-intellij-plugin#21
Please note that there is an tag( needIntellijDeveloperSupport ) on this issue.
Please add IDEA plugin support for this method. It lacks of such power instrument.
Please add IDEA plugin support for this method. It lacks of such power instrument.
@egsam98, this issue is tracked here
When I am in a good mood, I may submit a pr to implement this feature, which is not complicated for me.
Most helpful comment
My review of "Experimental because" section:
People got used to the extension methods thanks to Groovy, Kotlin, Scala and other alternative JVM languages.
Since Lombok is a syntax sugar library, IMO it's better to let other developers produce their libraries focused on this feature. There are many extension-ready libraries like Apache Commons as well.
So far many Lombok features were supported after they made their way to non-experimental status. For instance, IDEA plugin is waiting for this feature to become non-experimental
I definitely see scoped use-cases for it, if it's doable without huge implementation changes - IMO it's a good addition to the feature. Also, it will allow to gradually add them, on a per-method basis. At the same time, package annotation will help to use them in a code base where you have multiple classes in the same file. Both :+1: from me.