[datum] initial public push (IPP)

[Vicente Romero]

yes, interesting idea Tagir, we have to think about it

Thanks,
Vicente

On 11/08/2017 06:15 AM, Maurizio Cimadamore wrote:
> That's a nice idea - not sure if @Override is the right name for it 
> (after all, it's not overriding anything, it's more of an explicit 
> definition), but some mechanism like that would be helpful, yes.
>
> Maurizio
>
>
> On 08/11/17 05:35, Tagir Valeev 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
>