Constructor annotation

[Eva Krejcirova]

Good point!
In FX sources, we already use the @Default annotation which was used by 
annotation processor when generating the builders. Because of this, it 
has source retention policy, so it cannot be used by FXMLLoader. I was 
thinking about promoting this to runtime annotation but maybe your 
solution is better.

We should solve this for FX8 otherwise the FXMLLoader will behave 
differently from how the generated builders behaved.

Eva

On 16.10.2013 17:24, Tom Schindl wrote:
> One thing that just came to my mind is that maybe also need a way to
> define the default value to be used, with a builder I could e.g. define
> that the default for fields are different from their real native default.
>
> class MyBuilder {
>    private boolean a = true;
>    private int x = -1;
>    private Insets i = new Insets(10);
> }
>
> If we want to have a full replacement for builders the annotation must
> have the possibility define this (in future).
>
> public @interface NamedArgument {
>    String value();
>    String defaultValue();
>    Class<Converter> converterClass();
> }
>
> If no converterClass is given we'd have to do our best to auto-convert
> the String. I don't want to say that we should implement the default
> value definition in FX8 but it would feel more natural with an
> annotation per argument.
>
> Tom
>
> On 16.10.13 17:12, Tom Schindl wrote:
>> To me the JavaBean solution with one annotation looks error prone, does
>> anybody know why they did not use an annotation per field?
>>
>> Tom
>>
>> On 16.10.13 16:58, Stephen F Northover wrote:
>>> +1 for base.  Should we not follow closely what Java Beans is doing for
>>> consistency?  I realize that we can't have the reference.
>>>
>>> Steve
>>>
>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
>>>> Not to mention Tom's point that it can't be in the fxml module without
>>>> created unwanted (and circular) module dependencies. Seems like it
>>>> needs to be in the "base" module then, right?
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Richard Bair wrote:
>>>>> +1 this is my preference. It is useful for things other than FXML,
>>>>> and should be considered part of our javafx.beans API.
>>>>>
>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl
>>>>>> <tom.schindl at bestsolution.at> wrote:
>>>>>>
>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> when we retired builders, we caused a problem for FXML which doesn't
>>>>>>> have a way to create classes without default constructors. Back
>>>>>>> then we
>>>>>>> decided to use an annotation for this but never actually got to
>>>>>>> implement it and we need to fix this for FX8. I am in the process of
>>>>>>> adding this functionality to FXMLLoader but we need to decide how the
>>>>>>> annotation will look like and I could use some help with this.
>>>>>>>
>>>>>>> We cannot use already existing ConstructorProperties for this, because
>>>>>>> it's java.beans package and we don't want to create to dependency on
>>>>>>> this package in JavaFX, so we need to introduce a new annotation.
>>>>>>>
>>>>>>> We have two options:
>>>>>>>
>>>>>>> 1. Annotate the whole constructor:
>>>>>>> e.g.
>>>>>>>     @ConstructorArguments({"a", "b", "list"})
>>>>>>>     public ImmutableClass(int a, int b, Integer... list)
>>>>>>>
>>>>>>> 2. Annotate the arguments:
>>>>>>> e.g.
>>>>>>>     public ImmutableClass(@FXMLArgument("a") int a,
>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list)
>>>>>>>
>>>>>>>
>>>>>>> Which option do you like more and how should the annotation be named?
>>>>>> Option 2, but does it really have to hold FXML in the annotation name?
>>>>>> Where would you put the annotation? I think it should NOT be in the
>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML!
>>>>>>
>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used
>>>>>> by javax.inject)
>>>>>>
>>>>>> Tom