[datum] initial public push (IPP)

[Brian Goetz]

I think it is reasonable to view providing an explicit impl as an override -- it is within the spirit of the @Override annotation.  

That said, changing a field name will not be a binary or source compatible change anyway (though in a closed source base it may be safely refactored). 

Sent from my MacBook Wheel

> On Nov 8, 2017, at 6:35 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> Thank you for pushing this!
> 
>> If the user provides any of the above members explicitly, it will be used instead of the default defined by the compiler
> 
> Suppose we provide an explicit getter implementation. How can we
> assert an intention to override the default implementation, so we will
> get a compilation error if later field name is changed, but method
> name stays the same? Can we use @Override on the getter?
> 
> With best regards,
> Tagir Valeev.
> 
> On Wed, Nov 8, 2017 at 1:11 AM, Vicente Romero
> <vicente.romero at oracle.com> wrote:
>> 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