search

lishunli / projectlombok

Automatically exported from code.google.com/p/projectlombok
0 stars 0 forks source link

@Getter and @Setter naming #433

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The Getter and Setter annotations should have an optional String parameter, 
which when set alters the name of the generated method. This would be really 
useful for example on a project I am working on where the interfaces I have to 
implement are getXXX (boolean) hasXXX (boolean) etc etc etc.
I was surprised to see such a feature didn't already exist.

Original issue reported on code.google.com by the.md5e...@gmail.com on 2 Dec 2012 at 10:20

GoogleCodeExporter commented 9 years ago 
But that's not a defect, it is a feature-request.

Original comment by brinkman...@gmail.com on 4 Dec 2012 at 8:31

GoogleCodeExporter commented 9 years ago

Original comment by r.spilker on 4 Dec 2012 at 8:58

GoogleCodeExporter commented 9 years ago 
Couldn't see the button. Why do you even use this over Github?

Original comment by the.md5e...@gmail.com on 4 Dec 2012 at 11:03

GoogleCodeExporter commented 9 years ago 
@the.md5encryption(Comment #3): Because 'this' is much more awesome and does 
not require logging in. We manage the tagging, so that wasn't your problem.

Original comment by reini...@gmail.com on 11 Mar 2013 at 9:12

GoogleCodeExporter commented 9 years ago 
The 'default' parameter position is already taken up by AccessLevel, i.e. it's 
@Getter(AccessLevel.PROTECTED), so we can't change that to @Getter("hasFoo"). 
We could do something like @Getter(name="hasFoo") which is fair enough as a 
feature request I suppose, but this is actually an extremely complicated change:

A LOT of our code has to go out and look for existing getters/setters. For 
instance, @EqualsAndHashCode (and thus @Data, @Value, etc) use getters if they 
exist. It would be very strange if @EqualsAndHashCode can't find the getters 
generated by lombok itself, so we have to complicate that code by checking 
which name the getter was generated as.

So, technically, yeah, if we had infinite time, we'd implement this feature. 
But we don't.

A push request would be accepted, but we'd hold this one to an extremely high 
standard. It would need everything:

* Both a javac and an ecj implementation.
* Tests (ecj and javac!)
* Documentation updates
* Javadoc updates to the relevant annotations.
* Updates to @ToString, @EqualsAndHashCode, etc which all call helper methods 
to find out if a getter exists (that helper method would need to be updated).
* Some extra tests for all the other lombok annotations that look for getters 
to double check that the above method works.

If you do have such a patch or push request feel free to re-open this issue.

Original comment by reini...@gmail.com on 11 Mar 2013 at 9:19

GoogleCodeExporter commented 9 years ago 
Considering I've never touched the Lombok source, that is a fair ask :p
I'll keep it in the back of my mind, but if its not gonna happen, its not gonna 
happen - just unfortunate in the way all the getter / setter stuff has been 
coded with respect to other annotations.

Original comment by the.md5e...@gmail.com on 12 Mar 2013 at 1:24