> De: "Brian Goetz" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "John Rose" <[email protected]>, "amber-spec-experts" > <[email protected]> > 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
