Fluent Interface

[Harith Fannad]

Hello Lombok Team,
 how are you? I hope you are doing well. Thanks for your work, it makes our life easier and our code cleaner.
Guys, I have a question: whose idea was it to add the fluent interface pattern to the @Accessors annotation? I think that was an unfortunate decision. We need both as Java developers. We can't just abandon the getters and setters because many plugins use them, for example to create POJOs or serialize JSON.
I have a suggestion: a new annotation @FleuntInterface that has nothing to do with the annotation Accessors.

Thanks guys
You are great

Harith Fannad

[Reinier Zwitserloot]

> We need both as Java developers.

Well trodden ground. We disagree.

The point of fluent getters is __solely__ to make nicer API. An API with duplicated methods isn't nicer, it's worse. By a significant margin - the best code is code that is self-evident: Code whose signature elements (so, names, return type, parameter types) lead one to jump to a conclusion, and this conclusion is likely correct. That's the best code: It doesn't need documentation, or at best, documentation that simply confirms the obvious. If I see a class that has both a `year()` and a `getYear()` method, I won't jump to the conclusion: Oh, clearly, those are synonyms for my convenience. I start having to delve into the docs to confirm why in the blazes the class has duplicate methods. It also mucks up auto-complete dialogs, and causes pointless style debates for using the library (should one use `getYear()` or `year()`? Even if the docs clearly indicate one of the two to prefer, you've still ended up with a non-self-evident API now).

Lombok draws the line at features which serve only for abuse, or at least, it disregards the abuse scenarios (which having both "for API convenience" is!) when doing the 'math' on whether the feature is worth it, which is primarily a function of 'number of times this boilerplate is likely to come up in an average java project' multiplied by 'how much boilerplate code can be removed by lombok'. The 'likeliness' factor is near nil which means the feature doesn't make it.