search

lishunli / projectlombok

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

@Wither does not support wither methods overload #592

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I am attaching a sample NetBeans project where you just need to uncomment line 
23 to 25 to reproduce the issue. Basically the wither processor are not 
overloading methods correctly. I used the same approach for @Builder and it 
worked as expected.

Original issue reported on code.google.com by michel.g...@gmail.com on 11 Oct 2013 at 4:49

Attachments:

GoogleCodeExporter commented 9 years ago 
This is by design, consistent with other lombok annotations such as @Setter.

From the documentation on 
http://projectlombok.org/features/experimental/Wither.html

No method is generated if any method already exists with the same name (case 
insensitive) and same parameter count. For example, withX(int x) will not be 
generated if there's already a method withX(String... x) even though it is 
technically possible to make the method. This caveat exists to prevent 
confusion. If the generation of a method is skipped for this reason, a warning 
is emitted instead. Varargs count as 0 to N parameters.

Original comment by askon...@gmail.com on 11 Nov 2013 at 10:31

GoogleCodeExporter commented 9 years ago 
I know it's documented and it's consistent, however, this doesn't make it like 
it. Typically, I have a bunch of `ImmutableWhatever` fields and want the wither 
to accept any `Whatever`. So I write a short wither and delegate to the 
generated one (still saving quite some typing).

For this to work, I simply removed the corresponding test. This is a pretty 
dirty solution, but simple. Doing `ImmutableWhatever.copyOf` on each call site 
would be too much boilerplate. Using a different name would be too confusing.

The best solution would be a ctor doing this transformation and the wither 
accepting the same type as the ctor does (similar to how Builder works). A 
simpler solution would be something like `@Wither(force=true)` or annotating 
the handwritten wither with `@lombok.Ignore` like proposed in 
https://groups.google.com/d/msg/project-lombok/rmW9LB6Uddc/2ClRZ1L93UYJ

Original comment by Maaarti...@gmail.com on 13 Nov 2013 at 9:49

GoogleCodeExporter commented 9 years ago 
There are at least three cases, when Lombok refuses to generate a method for a 
good reason, but the user can know better: @Wither, @Setter, and @Delegate, see 
also

https://groups.google.com/d/msg/project-lombok/wEfnkDIboNk/6el9CDD3Us4J

As all those cases are nicely separated (by method name), we could use a single 
annotation to rule them all. I'm proposing that methods annotated with 
`@lombok.Tolerate` won't prevent the generation of equally named methods. I've 
implemented and tested it a bit, and I'd be happy to contribute it. A better 
name would be appreciated.

Original comment by Maaarti...@gmail.com on 31 May 2014 at 5:25

GoogleCodeExporter commented 9 years ago 
Actually, the status should be changed to Fixed (@Tolerate since v1.14.2).

Original comment by Maaarti...@gmail.com on 9 Jul 2014 at 10:26