Fwd: JDK 14 Preview Records constructors

Brian Goetz brian.goetz at oracle.com
Tue Jun 16 15:46:36 UTC 2020


> If I think that way that all constructors need to funnel through the
> canonical constructor for invariant checking, it makes more sense.
>
> You could go even a bit further and regard any code after this(…) in a
> non-canonical constructor as dead code. You can’t do much after, right?
> Except maybe logging and error-prone hacky stuff.

Pretty much, yes.

>
> Here some food for thought however. Lets imagine that Java has default
> parameters someday (would be a nice tandem with named innvocation):
>
>   
>
>      record Foo(int x, int y) {
>
>          public Foo(int x, int y, int a = 0, int b = 0) {
>
>              this(x + a, y + b);
>
>          }
>
>      }
>
>   
>
> Looks a bit like recursion / chicken-egg problem to me, but that’s on you
> compiler writers to figure out :P

Indeed, one of the (multiple) reasons that we don't _already_ have 
invoke-by-name with default parameters is how it works with overload 
resolution.  Languages tend to either have overloading or flexible 
declaration/invocation, and they are there to serve the same purpose, 
but having both at once can fight with each other.

>
> Ok sounds very reasonable. Now we could also imagine a singleton Record or
> Record’s that only allows a set of predefined instances. Those would only
> work if the constructor is private.

Or. make a public interface, a private implementation record, and a 
factory in the interface. Which raises an important point -- in some 
cases, records may be more useful as an implementation tool than they 
are as public API.

>
>
> I feared this would be an answer from your side. My standpoint is that so
> far Java was following more or less the slogans
>
> "Explicit is better than implicit",  "Readability counts. " and "There
> should be one-- and preferably only one --obvious way to do it."
>
> which I stole from Zen of Python PEP20. I feel the canoncal constructor is
> breaking this a bit. As for when Generics were introduced, I was too young
> for that and lambdas felt nicely integrated into the rest of the language.
> The migration was really smooth. With "var x = e" I’m veeeeery
> uncomfortable. Actually var was banned in our company per default checkstyle
> (ca. 50 devs, on Java 11 since release).
>
> I guess this is the point where you can’t make everyone happy.

Or, that people get comfortable at different rates.  Many features go 
through a cycle of denial / resistence / acceptance / enthusiasm, and 
that cycle runs at different speeds for different people.  Our job is to 
pick a speed so that overall, the platform moves forward so that it 
remains relevant and fun to use, but not so fast that everyone is 
pitched off the side of the wagon.


More information about the amber-dev mailing list