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" <[email protected]>
À: "amber-spec-experts" <[email protected]>
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.
