Draft JLS spec for records

[forax at univ-mlv.fr]

> 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
> representation.

yes 

> 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
> this.

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. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190905/e263b98c/attachment.html>