We already have RT-32860 (Add constructor annotations) for this. I've
copied this discussion to the JIRA issue.
Eva
On 16.10.2013 19:27, Stephen F Northover wrote:
Eva,
Perhaps @NamedArg is shorter and makes the code more readable?
If you don't have a JIRA already, please create one and paste in this
discussion. Interested parties can add themselves to the watchers list.
Steve
On 2013-10-16 1:25 PM, Richard Bair wrote:
Looks good to me.
On Oct 16, 2013, at 10:02 AM, Stephen F Northover
<steve.x.northo...@oracle.com> wrote:
It seems we are settling on @NamedArgument ... anybody disagree
strongly?
Steve
On 2013-10-16 11:45 AM, Richard Bair wrote:
Ya that works too.
On Oct 16, 2013, at 8:41 AM, Eva Krejcirova
<eva.krejcir...@oracle.com> wrote:
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.schi...@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
