Draft JLS spec for records
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Sep 5 19:10:14 UTC 2019
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 5 Septembre 2019 15:49:25
> Objet: Re: Draft JLS spec for records
>> can someone explain me why we need the constructor to be public ?
> The essence of records is: “the author gives up the right to decouple the public
> API from the representation.” That means that the construction, deconstruction,
> access, equality, hashing, and textualization protocols are derived from the
> There needs to be a deterministic, mechanically-derivable-from-the-state-vector
> way to construct a record instance. Serialization, for example, would use this
> for reconstructing the object; frameworks like O/R mappers would do the same.
> Allowing the user to withdraw the constructor from the API would undermine
Serialization is an opt-in mechanism, i've not problem with the constructor of a record being always public if the record is marked as Serializable.
But i don't think it's a good idea to make all records "serializable" (in the general sense) by default, it means that you can not use a record as an implementation of a public interface because the fact that it's a record is also part of the API. In fact it's worst because you have no way to opt-out.
Java serialization is not the best mechanism, mostly because of its implementation, but at least there is one thing right, being serializable is opt-in.
I believe we should follow the same principle by allowing the constructor to be public or private, you are opting for being serializable (in the general sense) or not.
> Now, you might say “but I want my API to have factories, not constructors,
> because constructors are old and smelly”*. And if factories were a language
> concept, I would agree 100%, and would prefer to have a private ctor with
> public factory. But factories are not a language concept, and it would be
> pretty questionable for the language to bless a name like “make” or “of” as the
> name for the automatically generated factory method.
one advantage of having a factory is that you provide a name, so having an automatic name is not better than "<init>".
> So while “public constructor” is not ideal, it’s less bad than the alternatives
> that have presented themselves so far.
> *Note that one of the biggest benefits of factories, that you might return a
> subclass, isn’t in play with records anyway, since records are final. The main
> thing a factory could do here is return a cached instance. Which is not
> nothing, but not quite as useful as factories are in the general case.
I believe the biggest benefit of factories is that your code is not in the middle of the initialization of the instance so you can actually debug it :)
Constructors are hard to debug when there are more than a list of this.x = x because your are adding the time (am i before or after this intitialization) in the equation.
Anyway, we are far from the discussion at that point.
More information about the amber-spec-observers