_Migrated from Google Code (issue 4)_
:bust_in_silhouette: reinierz :clock8: Jul 24, 2009 at 04:17 UTC
What steps will reproduce the problem?
Fix: If boolean field and the field name starts with 'has', use the field name as method name.
:bust_in_silhouette: r.spilker :clock8: Jul 24, 2009 at 11:04 UTC
Also, we might want to check if any of the is/has/get methods exists befor creating
one.
:bust_in_silhouette: r.spilker :clock8: Jul 25, 2009 at 21:10 UTC
If the field starts with "is" we don't want to prepend another "is". We need to make
sure that "is" or "has" is not the start of a longer word. So the next character has to
be title case. This ensures that a boolean field called hashCodeCalculated would get a
getter named isHashCodeCalculated instead of hasHCodeCalculated.
:bust_in_silhouette: reinierz :clock8: Jul 26, 2009 at 07:19 UTC
Implemented all suggested changes in commit a9d29896887ee35903bcb847eb4307637801bcc2.
NB: Roel, I haven't tested all borderline cases on this one!
:bust_in_silhouette: reinierz :clock8: Jul 26, 2009 at 07:30 UTC
Test ﹟1: Make boolean fields named 'isFoo', 'getBar', 'hasBaz' and 'hashFlooble'. This must generate methods
'isFoo(), hasBaz, getBar, and isHashFlooble.
On eclipse: Correct on all counts.
On javac: Correct on all counts.
Test ﹟2: Make boolean fields named 'isFoo', 'bar'. Then make methods named 'hasFoo', and 'getBar', and make
sure that neither field gets an auto-generated getter, and that both fields get a warning that no getter is
being made, with the alternate name stated in the warning message.
on eclipse: correct on all counts.
on javac: correct on all counts.
Thus, I'm verifying the change.
_End of migration_
Sorry, I see that it's an old thread, but do I miss something or was it reverted? Because it generates isHasFoo() for the field named hasFoo in v1.16.16.
@Ghedeon IIRC this has indeed been reverted. It makes the names sound better, but it's another "prefix-shedding", incompatible with javabeans and not very systematic. There (at least) following possibilities:
Why not give the developer the ability so set the exact getter/setter name they what to use?
For instance I have a Boolean getter I would like to call canAdd... rather than isAdd or hadAdd.
Something like the following would be nice:
@Getter(name="canAdd")
@Setter(name="setCanAdd")
private Boolean thisNameDoesNotMatter;
Most helpful comment
Why not give the developer the ability so set the exact getter/setter name they what to use?
For instance I have a Boolean getter I would like to call canAdd... rather than isAdd or hadAdd.
Something like the following would be nice:
@Getter(name="canAdd")
@Setter(name="setCanAdd")
private Boolean thisNameDoesNotMatter;