Loosening requirements for super() invocation
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Sat Jan 28 21:49:01 UTC 2023
On 28/01/2023 02:19, John Rose wrote:
> I must be missing your point here Maurizio… There is
> some corner case you are concerned with but I can’t see
> where the danger is.
My point was not about "danger" but about "complex programming model",
and "return on complexity". Allowing initialization of local fields
before super() call would at the very least cause observable behavior
changes in all the instance initializers of the class (there was such an
example in the previous version of the JEP I believe).
So my point was: why do we need to go there? That is not (anymore) about
allowing programs which were rejected for obtuse reasons. This starts
going down a path of messing with initialization order (e.g. moving a
field initializer, even if local, across the "super" call is _not_ a
compatible change).
It maybe failure of imagination - but aside from pathological cases
(like classes whose initialization lets `this` escape - which I think we
all agree are on the bad side of the spectrum) I can't think of why you
would want to do that. The fact that the JVM allows it, and that it does
so in a sound fashion (which is what I'd expect the JVM to do) is
irrelevant in my consideration.
To put it more clearly - it is quite clear as to why one might want to:
* do validation on constructor parameter before a super call
* pass constructor parameter twice
* do some complex initialization which requires control flow
These are things that add a net improvement on language expressiveness,
and do that with a very simple rule: you cannot spell `this` before the
super() call, which is easy to remember, and close to what users would
expect.
To add the next bit, the model is: you cannot spell `this` except if
it's an initializer of a field. But wait, not any field, it has to be a
"local" field (this names is, btw, not great, as in Java I only know
about "local variables") - so that concept also comes with the ride. Of
course these concepts aren't hard to teach, but I think before we go
there we should have better arguments of _why_ we need to, as the
examples I've seen so far seem a bit on the thin side. And, doing the
points above doesn't prevent us from doing more later, if needed.
Cheers
Maurizio
More information about the amber-dev
mailing list