diff options
author | Reinier Zwitserloot <reinier@tipit.to> | 2009-07-26 09:15:28 +0200 |
---|---|---|
committer | Reinier Zwitserloot <reinier@tipit.to> | 2009-07-26 09:15:28 +0200 |
commit | a9d29896887ee35903bcb847eb4307637801bcc2 (patch) | |
tree | e7947619e7b295588ea67a51008f41d79c5148f9 /website/downloadButton.svg | |
parent | 0d9bde828d548893108f78a281016150121b1d8d (diff) | |
download | lombok-a9d29896887ee35903bcb847eb4307637801bcc2.tar.gz lombok-a9d29896887ee35903bcb847eb4307637801bcc2.tar.bz2 lombok-a9d29896887ee35903bcb847eb4307637801bcc2.zip |
Addresses issue #4:
If boolean fields already start with a typical getter prefix (is, has, or get), lombok's @Getter will no longer generate its own prefix as well, so a field named 'hasFoo' will result in a getter named 'hasFoo()', not 'isHasFoo()'.
Also, if any likely getter name already exists for a boolean, a getter will not be generated. Thus, if your field is called 'hasFoo', and you already have a method named 'isFoo', then @Getter will not generate anything (and warn, unless the getter is being generated due to @Data).
This last mechanism works by taking the field name *AND* any other likely base names (defined by the field name being named as prefix+baseName, with prefix being is/has/get), and then prefixing all the likely fieldnames with is/has/get, and checking if any method with that name exists.
Of course, this means weird things are going to happen if you have 2 fields named 'isFoo' and 'hasFoo', but then, you'd be a real idiot if you did that.
Diffstat (limited to 'website/downloadButton.svg')
0 files changed, 0 insertions, 0 deletions