[datum] initial public push (IPP)

Remi Forax forax at univ-mlv.fr
Thu Nov 9 17:46:11 UTC 2017


yes, i'm curious too.
equals() contract requires to work with any types, so trying to generify equals i.e. introduce a constraint between the type of this and the type of the parameter does not seem to play well with the semantics of equals. Perhaps like Dart or Scala, you can separate the equals implementation in two parts, one that does the if/instanceof (and the nullcheck) and the other which is specific to the field of the datum so someone that would like to redefine equals can decide to either redefine the whole equals or only the part that cheks the fields. In that case, the question is why not doing that on every class and not only on data class.

cheers,
Rémi

----- Mail original -----
> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "Robert Gibson" <robbie_usenet at yahoo.co.uk>, "amber-dev" <amber-dev at openjdk.java.net>, "Brian Goetz"
> <brian.goetz at oracle.com>
> Envoyé: Jeudi 9 Novembre 2017 18:02:37
> Objet: Re: [datum] initial public push (IPP)

> 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


More information about the amber-dev mailing list