Loosening requirements for super() invocation

[Brian Goetz]

Indeed.  The "return on complexity" (RoC) is weak at best.

On 1/28/2023 4:49 PM, Maurizio Cimadamore wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230128/fff1a785/attachment.htm>