[datum] JavaFX properties support

[Nir Lisker]

And if I use __nonfinal will I get setters? Are they the overloaded
x(TypeOfX newX)?

Also, if I may ask, why is x() a preferred convention over getX() when
there's already a standard? Won't this cause a "cultural" conflict when
beans are already used as data classes?

On Wed, Jan 24, 2018 at 3:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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>
> 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
>>>
>>
>>
>
>