brian.goetz at oracle.com
Thu Nov 2 14:05:29 UTC 2017
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.
> ----- 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:
>> Comments welcome!
>> We'll be making a prototype available soon for folks to play with.
More information about the amber-spec-observers