[datum] initial public push (IPP)

[Vicente Romero]

On 11/09/2017 12:41 PM, Robert Gibson wrote:
> The idea is to remove the possibility of ‘always false’ equals comparisons “Hello”.equals(3) for data classes.  Your IDE might currently warn about them, but can we do better?
>
> The simplest approach is just
>
> __data class Point(int x, int y);
> // implies public boolean equals(Point p), maybe with a bridge method from equals(Object o)
>
> Point p = new Point(1, 2);
> assert p.equals(new Point(1, 2));
> // Doesn’t compile, hooray!
> //assert !p.equals(“point”);
>
> But that very quickly runs into problems
>
> // Oops, we lost transitivity
> assert !”point”.equals(p);
> Object o = p;
> // Oops, we got a ClassCastException (probably)
> assert !o.equals(“point”);
>
> And there are more pitfalls of course around inheritance, although the rule of “only one concrete class in a hierarchy” eases the pain a little.
>
> I suspect that backwards compatibility is going to win out pretty quickly (for example, Scala case classes and Kotlin data classes both define equals in terms of Any), but I note that C# records implement IEquatable<T>, an interface which has ‘only’ existed since C# 2.0
>
> I’m just interested to know if you have done any exploration of this space, or if it is completely out of scope and off the radar (to mix my metaphors a little)?

to my knowledge this is out of the radar right now, but what you are 
saying is interesting so I will bring the topic to an internal 
discussion. But I have to say that data classes is in principle a tiny 
feature and mostly for it's "1.0" version

>
> Thanks,
> Robert

Thanks,
Vicente

>
>> On 9 Nov 2017, at 18:02, Vicente Romero <vicente.romero at oracle.com> wrote:
>>
>> Hi Robert,
>>
>> On 11/09/2017 11:40 AM, Robert Gibson wrote:
>>> Hi,
>>> This looks promising.  I read Brian’s note [1] and I wondered if you have given any consideration to the idea of attempting to generify the equals() method for data classes?
>> Interesting question, we haven't spoken about it. Could you please provide a test case for this feature?
>>
>>> Thanks,
>>> Robert
>> Thanks,
>> Vicente
>>
>>> http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>>>
>>>> On 8 Nov 2017, at 12:28, amber-dev-request at openjdk.java.net wrote:
>>>>
>>>> Date: Tue, 7 Nov 2017 13:11:40 -0500
>>>> From: Vicente Romero <vicente.romero at oracle.com>
>>>> To: Amber dev <amber-dev at openjdk.java.net>
>>>> Subject: [datum] initial public push (IPP)
>>>> Message-ID: <a00cffb6-217b-7e04-ffd3-37f51934352e at oracle.com>
>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>
>>>> Hi all,
>>>>
>>>> We have just made public the development of data classes [1]. The
>>>> development will continue in the "datum" branch in the amber repo [2].
>>>> Data classes allow for more compact class declarations. Basically for
>>>> classes for which the state of the class can be declared in the class
>>>> header. The basic, informal, data class syntax is:
>>>>
>>>> ? __datum Name(Fields) { BODY } or for a body-less data class:
>>>> ??? __datum Name(Fields);
>>>>
>>>> here Fields is a list of fields, and each field can be:
>>>>
>>>> [@Annos] [ __nonfinal ] type name
>>>>
>>>> *Note:* __datum and __nonfinal are just place holders, the final keyword
>>>> to be used is still to be defined
>>>>
>>>> The fields are implicitly lifted onto fields of the class, with the
>>>> default accessibility of "package final", unless noted as non-final. Any
>>>> additional field declarations in the body are prohibited. Non-abstract
>>>> data classes are final. Data classes can be generic and can implement
>>>> arbitrary interfaces. Every non-abstract data class acquires:
>>>>
>>>> ?- a public constructor that takes fields in the order specified by the
>>>> field list, and initializes all fields;
>>>> ?- public getters for each field, whose name is same as the field;
>>>> ?- public equals(), hashCode(), and toString().
>>>>
>>>> If the user provides any of the above members explicitly, it will be
>>>> used instead of the default defined by the compiler. Abstract data
>>>> classes are permitted; but they get only a public constructor.? By
>>>> default the field access of abstract data classes is protected and they
>>>> are final.? In addition, data classes can extend abstract data classes.?
>>>> Also, data classes with no parent class have the new class
>>>> java.lang.DataClass as its parent.? Extension looks like:
>>>>
>>>> abstract __datum X(int x);
>>>> ??? __datum Y(int x, int y) extends X(int x);
>>>>
>>>> that is, the fields of X must be a proper prefix (arity, name, and
>>>> types) of Y's fields. For example the compiler won't accept this
>>>> declaration for Bad data class:
>>>>
>>>> ??? abstract __datum Sup(int x, int y);
>>>> ??? __datum Bad(int x, int y, int z) extends Sup(x, z); // field name
>>>> mismatch should be Sup(x, y)
>>>>
>>>> The current implementation doesn't allow data classes with an empty list
>>>> of fields, so:
>>>>
>>>> ??? __datum D2();? // compiler error
>>>>
>>>> we can relax this constraint in the future if there are sensible use
>>>> cases for which it makes sense to declare an empty data class.
>>>>
>>>> Please try it out and get back to us with your feedback!
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> PS. this code is under active development and bugs are being chased out
>>>> but still lurking, thanks a lot in advance for any bug report!
>>>>
>>>> [1] http://hg.openjdk.java.net/amber/amber/rev/04260073c6bd
>>>> [2] http://hg.openjdk.java.net/amber/amber