Getters... can they be final?

[Andy Kotlinski]

Hi,

Just wondering if it's possible to have my generated Getters marked final.  I didn't see this feature anywhere in the documentation, so I assume it's not there.  I'd like to see this added in the future if possible.

Thanks,

-Andy

[Reinier Zwitserloot]

It's not possible. We've done some analysis on options:

Option #1: Add an option; something like @Getter(makeFinal = true). This is simple to add and won't confuse anybody, but, if the plan is that you generally want ALL generated getters to be final, you're effectively making lombok boilerplate now. All your @Getters, everywhere, have (makeFinal = true) included on them which looks extremely ugly and throws an almost meaningless implementation detail in the face of anybody reading it. If you use @Value or @Data a lot, it gets worse, as we can't add makeFinal = true to that (we don't want Value/Data to have all the params of the constituent parts, it'd soon blow up into a bajillion options, bad idea), so you'd have to add @Getter(makeFinal = true) to those classes as well. even more boilerplate. The payoff has to be great indeed before we do this. Also, it leads to 'option bloat'; if this particular niche feature is fair game, i can think of about 50 others that have a similar argument for their inclusion, but I think we can all agree that @Getter with literally 50 different parameters is in the end worse than the current much simpler version. Sure, one of those 50 might be great for you, but the other 49 aren't, and having 50 options doesn't sound palatable to me. Thus, this is clearly a no go.

Option #2: Make it the default. Maybe, but, the only real reason to make them final is to prevent programmers from solving a problem in a way that leads to bad situations over time. I don't see how that's relevant here: it is not at all common for people to override getters, so if they ARE doing that, presumably they have a pretty good reason. Also, this would be a backwards compatibility breaking change, and presumably we'd have to offer an opt out too, which gets us back into the issue of parameter bloat. This isn't a good idea either.

Normally it would end there, but we are almost ready to release a new lombok feature called configuration, where you can configure certain aspects of lombok via settings files that live in your source folder(s). It's the perfect place for niche settings like this: Because the config system is hierarchical, you'd configure lombok to make all accessors (getter, setter, wither) final in only one place (root folder of your project), thus avoiding bloating up your code with tons of (makeFinal = true), and I'm less opposed to parameter bloat in a config file, because those are easier to document, are less 'in-your-face' (good thing; anything directly in your source files draws too much attention for such a trivial code generation modifier), and in general just feel like the right place for these kinds of settings.

That's the one we'll be going with. Feel free to add an issue for this so that we don't forget (something along the lines of 'add 'make accessors final' as a config option').

 --Reinier Zwitserloot

--
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.

[Marco Servetto]

This configuration feature looks quite nice.
I was thinking about doing with annotations, like

@Value(staticConstructor="of")
@interface MyValue {}

and then I can use @MyValue class Foo{}

It could be designed in such a way that you can have multiple
annotations in front of your new annotation, that will represent the
combination of all of them!

Marco.

[Martin Grajcar]

On Mon, Mar 24, 2014 at 9:21 PM, Marco Servetto <marco.s...@gmail.com> wrote:

This configuration feature looks quite nice.
I was thinking about doing with annotations, like

@Value(staticConstructor="of")
@interface MyValue {}

and then I can use @MyValue class Foo{}

It could be designed in such a way that you can have multiple
annotations in front of your new annotation, that will represent the
combination of all of them!

This can't  work because of the annotation target, at least not in general (though it looks like all relevant Lombok annotations allow Target.TYPE). I'd find the syntax rather counter-intuitive. Moreover, there's no such thing like order of annotations. But these are probably the lesser problem.

Something like

CustomAnnotation(@__={

    @Value(staticConstructor="of"),

    @RequiredArgsConstructor(onConstructor=@__(@Inject)),

    @Wither,

    @Accessors(fluent=true),

    @EqualsAndHashCode(exclude="cachedThingy")

})

@interface MyValue {}

looks nice to me, but I have no idea if it can be implemented (resolution again)?

[Reinier Zwitserloot]

All this requires resolution, and fairly complex at that. Which is very hard to do, would be slow, and fraught with subtle bugs.

Not gonna happen, unfortunately. Config is already implemented. It's based on files in your source folders.