Data classes

[Brian Goetz]

Yes, there are many features that a feature like data classes might want 
to pull in, like nullability / optionality / named constructor parameter 
invocations, to name a few.

However, treating nullability as a sub-feature of data classes would be 
a mistake, because, if a user has a class that does not quite meet the 
requirements for a data class, users will be badly tempted to wedge this 
square peg into the round data class hole just to get, say, nullability 
support.  If we're going to do something about nullability, it should 
work for all classes, data or otherwise.

You are right that there's a weak coupling, in that if we did that 
feature first, it might affect the defaults for data classes, whereas if 
we do data classes first, we might be boxed in with respect to defaults.



On 11/2/2017 9:34 AM, Remi Forax wrote:
> Hi Brian,
> there is an axis which is not mentioned in this document, the nullablility of the fields, it's somewhat like 'final' because fields should not non nullable by default, it asks the compiler to add codes in the constructors (the calls to requireNonNull) so it can have a not so simple interaction with the call to default.
>
> I will post several other mails on each sections later.
>
> cheers,
> Rémi
>
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 1 Novembre 2017 19:53:40
>> Objet: Data classes
>> At the following URL, please find a writeup containing our current
>> thoughts on Data Classes for Java:
>>
>>      http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>>
>> Comments welcome!
>>
>> We'll be making a prototype available soon for folks to play with.