[datum] JavaFX properties support

[Nir Lisker]

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