-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow noIsPrefix for getters on a per-getter basis #2464
Comments
IMHO there are just three usable options:
Of course, every rule has exceptions. The exceptions should be rare, otherwise the users of the library get lost guessing. Lombok doesn't support exceptional cases, it only cares about boilerplate. So I guess, you need to write some getters manually (possibly with Disclaimer: I'm not a project maintainer. |
JavaBeans actually permits both |
Nobody said the contrary. There must be a misunderstanding, @Maaartinus gave you rationales and solutions to your problem
will give you a isValue1(), getValue2(), getValue3(). |
Whether the "exceptions" are rare or not depend on what you're writing. In our case it's heading towards 50/50, and I can easily imagine cases where it might be the majority. I know that I can just implement the method. I can avoid Lombok entirely, with the same end result. I was just asking for a new feature to be able to configure this on a per-property basis, so that I can remove all trivial getters instead of just half of them. |
Why that many booleans?
I tend to see 'too many flags' as a warning sign that the programming model
has problems. It may be actually modelling the problem space, but..
usually, it's caused by too much procedural C-like code...
…On Sat, May 30, 2020, 03:05 Trejkaz (pen name) ***@***.***> wrote:
Whether the "exceptions" are rare or not depend on what you're writing. In
our case it's heading towards 50/50, and I can easily imagine cases where
it might be the majority.
I *know* that I can just implement the method. I can avoid Lombok
entirely, with the same end result. I was just asking for a new feature to
be able to configure this on a per-property basis, so that I can remove all
trivial getters instead of just half of them.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2464 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABIERI3K5OWYYUDOT3PMH3RUBLTXANCNFSM4NBFL5VA>
.
|
The codebase is just several gigabytes in size, so even a proportionally small number of boolean getters adds up in numbers overall. But the real answer is probably "because all these dumb JSON serialisation libraries force us to have them". :( |
That's ridulously large. My sympathies.
What JSON serialization libraries force you to have Boolean fields though?
Pretty sure Jackson doesn't...
…On Mon, Jun 1, 2020, 10:31 Trejkaz (pen name) ***@***.***> wrote:
The codebase is just several gigabytes in size, so even a proportionally
small number of boolean getters adds up in numbers overall. But the real
answer is probably "because all these dumb JSON serialisation libraries
force us to have them". :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2464 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABIERPECVOHB6MWEN5F4WLRUNROZANCNFSM4NBFL5VA>
.
|
They're not |
Thank you autocorrect ;)
…On Mon, Jun 1, 2020, 23:25 Trejkaz (pen name) ***@***.***> wrote:
They're not Boolean, just boolean.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2464 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABIEROOUMQOQ66R6GRS4MLRUQMFTANCNFSM4NBFL5VA>
.
|
We'd be adding an annoparam that everybody sees and which is completely irrelevant for 90%+ of all properties (all non-booleans), just to cater to a use case where you're replacing a one-liner method with an annotation that contains as many characters as the very code it is supposed to replace. Not worth the maintenance burden and throwing this in everyone's face, by miles. |
It's only a one-line method until you open your eyes and see the rest of the required boilerplate. So you'd actually be replacing 4 or 5 lines with a single parameter, which is definitely worth it for the readability if not the time saved. And people who don't want to use it can just ignore it. They don't have to see it in their code unless they're using it. |
Crap on ideas all you want. But don't make it personal, please. Tone down your comments, this isn't the first time you've come across as abrasive (and that's coming from me, which presumably says something). The point is to be constructive, insinuating that other participants in this issue are lazy or incapable of drawing out ideas to their logical conclusion is decidedly not constructive.
IDE autocomplete dialogs will show it. This line of arguing is not going to change the status of this issue.
Exactly. Which is why this feature is dead in the water. The maintenance burden is significant, and that the linkage is weird: Changing the getter name doesn't just change the getter lombok generates, but also the equals and hashcode, with/builder 'deconstructors', and who knows what else. The right place for messing with names is To be crystal clear: This is never going to be added to |
I am inclined to agree with OP that it would be a useful feature to enable the naming of specific fields' accessors to be coerced using annotations. Trying to figure out how to do that has led me here, after all. I do find it surprising that Lombok hasn't adopted an approach similar to that used by libraries such as Jackson, whereby pretty much every globally configurable option can be overridden using annotations both at the class and the field level, as appropriate. |
Describe the feature
Depending on the name of the property, sometimes
isUpdated()
makes sense and other timesisWasUpdated()
makes no sense so naming itgetWasUpdated()
is preferred.We can configure all such methods to be named with
get
in the config file of course, but sometimes I'd still like to be able to have methods named withis
. :(So I'd like something along the lines of:
Describe the target audience
People who are opinionated about the naming of bean methods. ;)
Additional context
None?
The text was updated successfully, but these errors were encountered: