----- Mail original ----- > De: "Brian Goetz" <[email protected]> > À: [email protected] > Cc: "amber-spec-experts" <[email protected]> > Envoyé: Jeudi 2 Novembre 2017 16:05:33 > Objet: Re: Data classes
>> 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 to specify that >> the compiler will not generate a requireNonNull inside the principal >> constructor and that equals or hashCode do not need nullchecks. > > Not really a fair comparison. The keywords suggested like "non-final" > are not adding new concepts; they are merely making explicit something > that was previously implicit. They are more akin to allowing the > "package" keyword to describe the default accessibility of class fields, > rather than a new feature. Non-nullability, on the other hand, is indeed > a new feature. And, it is not a simple property of fields (well, it > could be, but I suspect users would find that to an unsatisfying > interpretation of "support for non-nullity.") There is no keyword in Java for defining a nullable field in Java, but not in SQL so this is not really a new concept, anyway, this is not the point here. > > Ignoring that, what I think you're saying is "You don't need to do > full-blown nullity propagation, you could simply have an 'annotation' > that triggers a null check on data class constructors." And if that's > what you're saying, I agree, we could do that. 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 generated, the question is how to tell the compiler to generate those precondition for me. As i said, it's a littel more general that just the constructor because you want setter to also have that nullcheck and the compiler can leverage that knowledge to generate better code for equals and hashCode. > But I suspect the limitations of this would very quickly turn opinion > negative. (Can't > use it on non-data classes. Can't use it on locals. Using it on > non-final fields starts to get messy fast -- do we have to do this on > all field writes? Etc.) Once you generate codes, people will want to be able to generate codes for non-data class, it's not something specific to what i'm proposing here. Again, the point is not about field or local variable, it's about enforcing preconditions at boundaries in a generated code. Rémi
