On 2017-11-03T13:19:09 +0100
fo...@univ-mlv.fr wrote:
>
> Yes, the point is about encapsulation, boundaries, as you have written.
> We used to insert Objects.requireNonNull at the start of public methods to
> validate preconditions, given that the primary constructor of a data class is
> now gene
- Mail original -
> De: "Brian Goetz"
> À: fo...@univ-mlv.fr
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 2 Novembre 2017 16:05:33
> Objet: Re: Data classes
>> In the proposal, you discuss about adding keywords like "non-final, unfinal,
>
On 2017-11-02T11:05:33 -0400
Brian Goetz wrote:
> > In the proposal, you discuss about adding keywords like "non-final,
> > unfinal, mutable", i.e. considering that there can be a different set of
> > keywords for data class declaration which is different from the one we have
> > on fields. In
In the proposal, you discuss about adding keywords like "non-final, unfinal,
mutable", i.e. considering that there can be a different set of keywords for data
class declaration which is different from the one we have on fields. In that spirit, we
can have a flag like nullable, maybenull, etc
ecify that
the compiler will not generate a requireNonNull inside the principal
constructor and that equals or hashCode do not need nullchecks.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "amber-spec-experts"
> Envo
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 d
This looks great!
One thing springs to mind with the accessors: Is it possible that the
generated accessor methods could participate in the implementation of
interfaces? For example:
interface Vector
{
double x();
double y();
double z();
}
__data class Vector3 (d
This is a very good and a pleasant read, thank you!
Especially nice to see a clear definition of design requirements.
I have several follow up questions:
*
do you envision data classes as Java language feature or JVM
platform feature?
Are additional features such as externalizati
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 int
On 2017-11-02T11:31:06 +
Maurizio Cimadamore wrote:
> Hi Mark,
> the code that is generated on a datum is essentially like real code that
> you would otherwise have typed yourself. In other word, think of it as
> ACC_MANDATED, not as ACC_SYNTHETIC. It is something that the compiler
> can f
Hi Mark,
the code that is generated on a datum is essentially like real code that
you would otherwise have typed yourself. In other word, think of it as
ACC_MANDATED, not as ACC_SYNTHETIC. It is something that the compiler
can fully reason about during type-checking and, as a consequence, it
m
On 2017-11-01T14:53:40 -0400
Brian Goetz wrote:
> 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 f
12 matches
Mail list logo
