RE: Constructor annotation
Hi
I'd prefer the second option, because the correlation of the order of arguments
in the annotation and in the constructors parameters is irritating and error
prone.
The way it is structured in option two is seen elsewhere also. So, nothing new
to learn/absorb.
@FXMLArgument is a useful name to describe what's going on.
My 2 cents...
Regards
Claus
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Eva Krejcirova
Sent: Mittwoch, 16. Oktober 2013 11:22
To: openjfx-dev@openjdk.java.net
Subject: Constructor annotation
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?
Thanks,
Eva
RE: Constructor annotation
I would prefer @FXMLConstructor and for the names of the parameters to be
automagicaly detected and linked, and then an optional @FXMLArgument to allow
us to specify if the actual name deviates from the name of the parameter.
I understand this can be an issue, as parameter names are not retained, but
we can fetch either from the debugging symbols, or at compile time. _
From: Claus Luethje [mailto:claus.luet...@osys.ch]
To: Eva Krejcirova [mailto:eva.krejcir...@oracle.com],
openjfx-dev@openjdk.java.net [mailto:openjfx-dev@openjdk.java.net]
Sent: Wed, 16 Oct 2013 11:26:12 +
Subject: RE: Constructor annotation
Hi
I'd prefer the second option, because the correlation of the order of
arguments in the annotation and in the constructors parameters is irritating
and error prone.
The way it is structured in option two is seen elsewhere also. So, nothing
new to learn/absorb.
@FXMLArgument is a useful name to describe what's going on.
My 2 cents...
Regards
Claus
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Eva Krejcirova
Sent: Mittwoch, 16. Oktober 2013 11:22
To: openjfx-dev@openjdk.java.net
Subject: Constructor annotation
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?
Thanks,
Eva
Re: Constructor annotation
Hi Jack,
On 16.10.2013 13:12, Jack Moxley wrote:
I would prefer @FXMLConstructor and for the names of the parameters to
be automagicaly detected and linked, and then an optional
@FXMLArgument to allow us to specify if the actual name deviates from
the name of the parameter.
I understand this can be an issue, as parameter names are not
retained, but we can fetch either from the debugging symbols, or at
compile time.
This would be nice, but I don't think that it's feasible in FX8 time
frame, unfortunately.
Eva
*From:* Claus Luethje [mailto:claus.luet...@osys.ch]
*To:* Eva Krejcirova [mailto:eva.krejcir...@oracle.com],
openjfx-dev@openjdk.java.net [mailto:openjfx-dev@openjdk.java.net]
*Sent:* Wed, 16 Oct 2013 11:26:12 +
*Subject:* RE: Constructor annotation
Hi
I'd prefer the second option, because the correlation of the order
of arguments in the annotation and in the constructors parameters
is irritating and error prone.
The way it is structured in option two is seen elsewhere also. So,
nothing new to learn/absorb.
@FXMLArgument is a useful name to describe what's going on.
My 2 cents...
Regards
Claus
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
mailto:openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net
mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Eva
Krejcirova
Sent: Mittwoch, 16. Oktober 2013 11:22
To: openjfx-dev@openjdk.java.net mailto:openjfx-dev@openjdk.java.net
Subject: Constructor annotation
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?
Thanks,
Eva
Re: Constructor annotation
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
Re: Constructor annotation
On 16.10.2013 11:26, Tom Eugelink wrote:
Would the duality of using the parameter info when available or else
the annotation (2nd option) be an viable approach?
This is probably doable but I am not sure whether we want to turn on the
parameter info for the whole JavaFX - last time I checked it was not
possible to specify that we need it only for constructors, so the class
files then contain names of arguments of all methods even if we don't
need them.
Eva
Tom
On 2013-10-16 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?
Thanks,
Eva
Re: Constructor annotation
+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
Re: Constructor annotation
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
Re: Constructor annotation
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
Re: Constructor annotation
+1 for base module
+1 for option 2
Only thing that troubles me is the readability if the annotation is long..
you will end up with a lot of boilerplate annotation characters vs. content
in the constructor argument declaration...
-Sven
On Wed, Oct 16, 2013 at 5:12 PM, Tom Schindl tom.schi...@bestsolution.atwrote:
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
--
Sven Reimers
* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader NetBeans: http://community.java.net/netbeans
Desktop Java:
http://community.java.net/javadesktop
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com
* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers
Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
http://www.linkedin.com/groups?gid=107402
http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497
Re: Constructor annotation
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();
ClassConverter 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
Re: Constructor annotation
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();
ClassConverter 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
Re: Constructor annotation
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();
ClassConverter 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
Re: Constructor annotation
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();
ClassConverter 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
Re: Constructor annotation
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();
ClassConverter 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
Re: Constructor annotation
NamedArg, like a pirate :-)
On Oct 16, 2013, at 10:27 AM, Stephen F Northover
steve.x.northo...@oracle.com 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();
ClassConverter 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
Re: Constructor annotation
+1
Am 16.10.2013 um 19:28 schrieb Richard Bair richard.b...@oracle.com:
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();
ClassConverter 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
Re: Constructor annotation
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();
ClassConverter 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
