[datum] JavaFX properties support

[Brian Goetz]

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
> [2]
> 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
>
>
> - Nir