search

lishunli / projectlombok

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

@DefaultValue support for final variables. #571

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.This is an enhancement iam asking.
2.
3.

What is the expected output? What do you see instead?
I must be simply able to say

@DefaultValue("3.1415") private final double pi;

so if some one didnt pass this in constructor or the staticConstructor for a 
value in pi; it must be taken from default. So relax pi from constructor args 
or the of method args required list; as u have @DefaultValue.

Why am i asking this?

this helps quite a lot when u want to do 
@FieldDefaults(level = AccessLevel.PRIVATE, makeFinal = true)
Else just b'cos you dont support @DefaultValue i need to break pi to a 
@NonFinal which breaks the rhythm.

What version of the product are you using? On what operating system?
lombok 12
windows/linux.

Please provide any additional information below.

Original issue reported on code.google.com by venkates...@gmail.com on 1 Sep 2013 at 8:14

GoogleCodeExporter commented 9 years ago 
Providing defaults as String, which is basically the only usable format, would 
work for, well, Strings. Or other primitives for which a canonical way of 
parsing a String is specified, and even that becomes unwieldy: what if the 
specified default String does not represent a valid value?

Doing this for any other type of object is nearly impossible. Frankly, I don't 
see this going to happen. Unless Reinier has some brilliant idea...

Original comment by askon...@gmail.com on 2 Sep 2013 at 3:28

GoogleCodeExporter commented 9 years ago 
I guess this feature won't get classified as useful enough, but maybe I can 
propose a better syntax:

class Crazy {
@AllowAssignmentInConstructor
private final double pi = Math.PI;
Crazy() {}
Crazy(double pi) {this.pi = pi;}
}

Lombok would remove the initializer expression and add an assignment to the 
first ctor.

Original comment by Maaarti...@gmail.com on 6 Sep 2013 at 12:54

GoogleCodeExporter commented 9 years ago 
@askoning: Is it okay if someone else has the brilliant idea?

Because what Maaartinus said, that'd work. Low on our priority list, though.

Original comment by reini...@gmail.com on 10 Oct 2013 at 9:09

GoogleCodeExporter commented 9 years ago 
By all means. It looks more sane at the least :)

Original comment by askon...@gmail.com on 10 Oct 2013 at 9:13

GoogleCodeExporter commented 9 years ago 
Maybe this is what the AllArgsConstructor should do, even without any 
@AllowAssignmentInConstructor annotation. And maybe not: When somebody 
specifies both a final field with an initializer and AllArgsConstructor, this 
is probably an error.

The current behavior is that "All" means something like "all non-initialized 
final fields". This contradicts the documentation stating that "An all-args 
constructor requires one argument for every field in the class".

I guess the current behavior is fine and it's what people expect (despite the 
prefix "All" being wrong). So I'd suggest to fix the documentation.

Original comment by Maaarti...@gmail.com on 15 Oct 2013 at 8:30