[datum] initial public push (IPP)

[Tagir Valeev]

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