<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">What we're seeing here is
something that happens all the time -- we start with a notion of
"hey, it would be great to improve the language in X way", and
then, as we start to write down specifics, realize that there
might be a better design center. <br>
<br>
We got here by observing "gee, the VM is much more tolerant than
the language here, maybe we should align the language to the
VM", along with some obvious examples of code we can't write
today that we'd like to be able to write. <br>
<br>
As we look at the implications of this, though, we start to see
that the cost/risk/complexity keeps cropping up in the
lower-value aspects. To summarize, here are the things you
originally proposed to align:<br>
<br>
- Allowing statements before the this/super;<br>
- Choosing different super/this ctors in different paths;<br>
- Initializing fields prior to this being DA.<br>
<br>
I think we can agree that the first bullet subsumes most of the
pain that users are in; it addresses things like "putting logic
where it belongs", allowing the same computed value to be used
multiple times without recomputing it, etc. The second feels
fairly niche, and while I can certainly imagine occasionally
wanting it, is probably 100x less common than the first, and is
where the vast majority of new spec complexity would come from.
The third seems a workaround for classes that are already kind
of broken with respect to this-escape, and I'm not sure we win
by encouraging this (since there's still an escaping `this`.) <br>
<br>
So it feels to me that the emerging consolidated design center
is "statements before this/super". The spec impact is quite
small and compact, and the expressiveness impact is pretty
significant. I think rallying around this consolidated center
will result in a better chance of success, and a stronger
payoff.<br>
<br>
<br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 1/26/2023 11:12 AM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxtqE=fbU7qWPd6i=uiw2RJEzONFVj5fQjyuT4WA6=dMUw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>Hi Maurizio,</div>
<div><br>
</div>
<div>Thanks very much for taking time to review.<br>
</div>
<br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 26, 2023 at 8:55
AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>One example that I didn't get was the NullPointer vs.
IAE - to me this seems another case where you want to
validate the parameter before passing it to the superclass
constructor - e.g. the same as the very first example. For
this reason, this example seems weak to me - and the JEP
would probably be better off with it omitted (unless I
missed some more subtle point, which is possible). </div>
</blockquote>
<div><br>
</div>
<div>Yes... I also thought maybe we should combine those two
examples into one. You've confirmed the hunch so I'll make
that change.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> what if the class initialized a protected field in the
superclass before the superclass constructor is called?</div>
</blockquote>
<div><br>
</div>
<div>That possibility may seem "weird" because it's a new
possibility for the first time in 25+ years, but I'd argue
that with a little analysis it turns out it doesn't actually
lead to any problematic or surprising outcome.<br>
</div>
<div>
<div><br>
</div>
<div>One could also argue that the language already allows
much
weirder things, like 'this' escapes where a subclass can
observe a supposedly final field with the wrong value...<br>
</div>
<div><br>
</div>
</div>
<div>Anyway, here's a breakdown of what happens if a subclass
writes to a superclass field prior to super():<br>
</div>
<div><br>
</div>
<div>If the superclass field is final, assignment is not
allowed - you get the usual "cannot assign a value to final
variable x" (no change here).</div>
<div><br>
</div>
<div>
<div>Otherwise, before super() is invoked, the field may not
be read, and invocation of superclass methods are
disallowed, so the field's value can have no effect on
anything.</div>
<div><br>
</div>
<div>When super() is invoked, either the superclass
constructor overwrites the value or it doesn't (if it
reads the value, then presumably that's intentional).<br>
</div>
<div><br>
</div>
<div>If the superclass constructor overwrites the value, the
field gets its new value, as expected.<br>
</div>
<div><br>
</div>
<div>If the superclass constructor doesn't overwrite the
value, the field retains the value written by the
subclass, as expected.</div>
</div>
<div><br>
</div>
<div>So in a nutshell, it behaves as one would expect: either
the superclass constructor overwrites the value, or it
doesn't. Life goes on.</div>
<div><br>
</div>
<div>(And if you don't like subclass constructors writing to
your fields prior to super(), you can make them private or
final, or just overwrite them in your constructor.)</div>
<div><br>
</div>
<div>So yes this scenario is new and different, but I don't
think it's fair to say it's problematic. It's just new.<br>
</div>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>My feeling is that it would be better to start
simple(r), and, at least for the time being, not to give
instance field initializers any special treatment.</div>
</blockquote>
<div><br>
</div>
<div>Certainly agree it would be simpler... but it would be at
the cost of eliminating the only tool we'll likely ever have
for dealing with a superclass 'this' escape, which is one of
the primary motivations behind this change.</div>
<div><br>
</div>
<div>But back to the crux... if what you're saying is that
you're worried about the uncertainty around initializing
fields prior to super(), does the earlier breakdown showing
that it's harmless (so to speak) help any?</div>
<div><br>
</div>
<div>Thanks,<br>
</div>
<div>-Archie<br>
</div>
<div> </div>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>