-
-
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
@Getter custom method name #836
Comments
👤 mibac138 🕗 Mar 21, 2015 at 13:35 UTC I think it would be great if we could in @ Getter pass argument which will be methods name. For example: @ Getter(name="isTrue") or @ Getter(name="isRunning") |
👤 mibac138 🕗 Mar 21, 2015 at 13:36 UTC For @ Setter it would be good too I think. |
End of migration |
Any progress on this? |
Any progress on this? One motivation would be customization of getter/setter names for field names starting with underscore. In my case, I need setter named |
Yep, will be nice to have this imlemented |
Regarding underscores: you can add them as field prefix in
The would remove them from the getter/setter names, |
Nice try, however, it's getting even worse: "Not generating getter/setter for this field: It does not fit your @accessors prefix list". |
I too would like to be able to set custom names or characters to ignore. In my example, I would like getter/setter names to ignore the I'd like |
Would be a nice feature |
@dslivka @blindgoat please take a look at |
Another possible use-caseBoolean properties don't always follow the same scheme — even within the same class. For example:
And the problem is hardened by the fact that both schemes could be used within the same project and even within the same class (even the same class P.S.: Another possible solution for the problem described in this comment might be not to remove ResumeIn fact, current getter/setter name generation scheme is non-ideal. And whatever we will change it to, it would be non-ideal either. Allowing custom getter/setter names would make lives of those-who-struggle-from-current-glitches (e.g. from #757) easier. |
I feel this issue is appropriately addressed in lombok right now with |
@rzwitserloot, surely not.
|
Sometimes Please correct me if this is already possible on a per-field basis. |
@JoshMcCullough It's not possible and there are IMHO only three sane choices for a getter name (all three are supported):
Using anything else adds some semantics to where it IMHO does not belong to. A variable called "continueExecution" should be always called just that (possible with a semantic-less prefix), not "shouldContinueExecution" nor "mustContinueExecution" nor "willContinueExecution". IMHO applying grammar or making it sound better is much less important than consistency - one day, you may need to make some tool understand your conventions. Sometimes it leads to misleading names, like "getReady", but then I'd just call my variable "isReady" and the name of the getter "getIsReady" can't mean anything but "get isReady". YMMV. That's just my personal opinion. I'm not in charge of the project, but I guess it won't get implemented because of these reasons. |
@Maaartinus Fair point, in this example |
@Maaartinus, you somehow miss very important thing: if you call you variable |
@o-pikozh It's you who is missing thing: https://projectlombok.org/features/GetterSetter
It's somewhat hidden... and probably not much used. IIRC it was me, who added this feature (but I'm not sure anymore) as I hate the default. |
@Maaartinus, AFAIK, in that case it would be (And I am not even talking about the fact that it's global setting, not field-wide and not even class-wide.)
|
@o-pikozh AFAIK, it must be I've just checked it and it works like I wrote. I had to check as I'm using
which makes it irrelevant.
Do you want talking it? I doubt it, as the only IMHO plausible reason for this setting is that you want a systematical naming. This makes per-field or per class settings useless as they'd spread even more chaos than the crapification. |
@Maaartinus, you're right, it's The |
@o-pikozh Agreed that the name isn't very good (I originally proposed However, anyone can improve the documentation, just clone the repo, edit |
@Maaartinus, anyone can improve the code as well, the same as documentation (but that doesn't mean we can't discuss current state). What bothers me the most in the current default behavior is not what exactly prefix is added, but the fact that existing prefixes are removed. I.e. I don't care too much whether |
@o-pikozh Sure, but just changing the name won't be any improvement, even if the new name was perfect (because of compatibility). I proposed you (and everyone else) to improve the docs as a starting point. I fully agree about what you wrote about the brain-damaged prefix removal; that's one reason why I say "javabeans crapification". I also agree that "noIsPrefix" says nothing about the removal prevention. As changing the feature name improbably gets approved, I'd suggest you to PR the docs. |
Migrated from Google Code (issue 801)
The text was updated successfully, but these errors were encountered: