[datum] JavaFX properties support

[Nir Lisker]

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> 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
>> [2]
>> https://docs.oracle.com/javase/8/javafx/properties-binding-t
>> utorial/binding.htm
>> [3]
>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/a455aff48
>> e48/modules/javafx.graphics/src/main/java/javafx/scene/shape/Line.java
>>
>>
>> - Nir
>>
>
>