[datum] JavaFX properties support

[Brian Goetz]

x() and y().

On 1/24/2018 7:04 AM, Nir Lisker wrote:
> I understand, but your comment about JavaBeans accessor naming 
> conventions made me wonder: in the example in the datum document, the 
> class has a comment "// public read accessors for x and y"; what are 
> these if not getX() and getY()?
>
> On Tue, Jan 23, 2018 at 3:48 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Yes, it's too much to ask :)
>
>     You even illustrate part of the reason in your mail -- in alluding
>     to all the complexities you've dropped to "keep the idea simple."
>     But those simplifications never sit still for long.  What is a
>     satisfying simplification for one person's idea of properties is
>     completely unacceptable to someone else -- the range of (mutually
>     incompatible) features that have been described as "properties" is
>     quite broad.
>
>     While I can't blame anyone for hoping that we'll have a solution
>     for properties while we're at it, it's definitely way outside of
>     the scope of what we're trying to do with data classes (which is
>     already hard enough.)  And we're definitely not interested in
>     burning (questionable) API design conventions into the language,
>     like the JavaBeans accessor naming conventions.
>
>     Sorry,
>     -Brian
>
>
>
>
>     On 1/22/2018 7:18 PM, Nir Lisker wrote:
>
>         Hello,
>
>         Iv'e read the summary on datum[1] and read some previous
>         discussion on this
>         list, but haven't downloaded and used it myself. I'd like to
>         open a can of
>         worms by bringing up the issue of boilerplate in JavaFX
>         properties (I will
>         use FXP to distinguish from the usual use of "property").
>
>         An FXP is defined as shown in [2] in example 1-1. The
>         definition requires:
>         1. declaration (and initialization)
>         2. getter for the property
>         3. getter for the property value (which is a delegate to the
>         internal
>         getter of the property)
>         4. setter, same as 3
>
>         When there are several properties a lot of boilerplate is
>         created, as
>         demonstrated in the Line class[3] lines 130-276 (though the
>         initialization
>         there is more elaborate than a SimpleXxxProperty constructor).
>
>
>         IF datum does the following:
>
>         __data class Point(IntegerWrapper x, IntegerWrapper y) { }
>
>         desugars to
>
>         final class Point extends java.lang.DataClass {
>              final IntegerWrapper x;
>              final IntegerWrapper y;
>
>              public Point(IntegerWrapper x, IntegerWrapper y) {
>                  this.x = x;
>                  this.y = y;
>              }
>
>              public IntegerWrapper getX() {
>                  return x;
>              }
>              // same for y
>
>              // all the other stuff
>         }
>
>         then maybe it's not too much to ask for something along the
>         lines of:
>
>         __data class Point(IntegerProperty x, IntegerProperty y) { }
>
>         desugars to
>
>         final class Point extends java.lang.DataClass {
>              final IntegerProperty x;
>              final IntegerProperty y;
>
>              public Point(IntegerProperty x, IntegerProperty y) {
>                  this.x = x;
>                  this.y = y;
>              }
>
>              // the name of the getter of the field changes according
>         to specs
>              public IntegerProperty xProperty() {
>                  return x;
>              }
>
>              // new method for value getter
>              public int getX() {
>                  return x.get();
>              }
>
>              // new method for value setter
>              public void setX(int xValue) {
>                  x.set(xValue);
>              }
>
>              // same for y
>
>              // all the other stuff
>         }
>
>         To keep the idea simple, Iv'e dropped the discussion about
>         finality,
>         un/boxing, explicit "overriding" of auto-generated code etc.
>
>         I'd like to note 2 things:
>
>         1. FXP already have a sort of elevated status in the JavaDoc
>         and its
>         generation tool: the doc is written only on the field and is
>         "attached" to
>         the other methods on generation, and there is a special
>         properties section
>         for them in the resulting doc.
>         I'm mentioning this as a precedent for FXP being treated
>         differently. I
>         believe they represent a "data carrier type" of their own with
>         ideas of a
>         reactive paradigm - listeners and bindings. Since datum is
>         actually trying
>         to solve a problem of "data carrier type" (though above I used the
>         boilerplate hook) I believe this is the place to address the
>         FXP issue. I
>         even believe they should be a lower level construct, but this
>         is out of
>         scope.
>
>         2. At the risk of being crucified, I'll mention that Lombok
>         has had some
>         requests and discussions on this. I'm mentioning it as a
>         source that there
>         is an audience for this support.
>
>
>         [1]http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>         <http://cr.openjdk.java.net/%7Ebriangoetz/amber/datum.html>
>         [2]
>         https://docs.oracle.com/javase/8/javafx/properties-binding-tutorial/binding.htm
>         <https://docs.oracle.com/javase/8/javafx/properties-binding-tutorial/binding.htm>
>         [3]
>         http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/a455aff48e48/modules/javafx.graphics/src/main/java/javafx/scene/shape/Line.java
>         <http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/a455aff48e48/modules/javafx.graphics/src/main/java/javafx/scene/shape/Line.java>
>
>
>         - Nir
>
>
>