<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Archie,<br>
the JEP is very well written, good job.</p>
<p>I have been bitten in the past by the problems you describe in
the JEP, so I'm very sympathetic with this work.</p>
<p>The examples you have included do a very good job at describing
the "limitations" that we have all gotten (too?) used to. Being
able to dynamically decide which superclass constructor to call is
very powerful, and the examples you have with complex
initialization are very shiny (in a good way :-) ).</p>
<p>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).</p>
<p>As stated in the goals of the JEP, your aim is to align the JLS
with what the JVMS allows - which is generally a good and noble
starting point. That said, I find that the JEP goes perhaps a
little too far in that direction, especially when it shows
allowing initialization of instance fields _before_ the superclass
constructor is called. I understand that this does not violate the
top-down principle, and that the JVMS caters for it, but seeing
that in a program seems odd, and all sort of questions started
popping up in the back of my mind - e.g. what if the class
initialized a protected field in the superclass before the
superclass constructor is called? And, the fact that depending on
whether field initialization is done before or after super leads
to different error messages (as you show in the JEP) seems also
potentially surprising.</p>
<p>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. That is, if you refer to `this` before the
superclass constructor has been called, even to set a field, you
get an error. I don't think we would lose too much: as your
examples show, there's quite a lot of "obviously correct" stuff
that this JEP would allow, even w/o descending into more
questionable territory (e.g. instance field initialization). In
fact, the only example that would benefit from assigning fields
before the superclass constructor call, is a "bad" case of
escaping this - not sure how much it's worth doing to support this
TBH.</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 20/01/2023 17:37, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxu-JbuTN9o5LhtBVtmJc7w8_3o7tg-w+iNNP_UKbiP4WA@mail.gmail.com">
<div dir="ltr">On Wed, Jan 11, 2023 at 10:27 AM Vicente Romero
<<a href="mailto:vicente.romero@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">vicente.romero@oracle.com</a>>
wrote:
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>For the code before super() work (<a href="https://bugs.openjdk.org/browse/JDK-8194743" target="_blank" moz-do-not-send="true">JDK-8194743</a>),
is it OK to file a PR before there is a JEP?</div>
</div>
</div>
</blockquote>
<br>
it could be done either way but I think that going for the
JEP first is usually a better approach<br>
</div>
</blockquote>
<div><br>
</div>
<div>OK, JEP filed here: <a href="https://bugs.openjdk.org/browse/JDK-8300786" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8300786</a></div>
<div><br>
</div>
<div>Fire away :) <br>
</div>
<div><br>
</div>
<div>-Archie<br>
</div>
</div>
<br>
-- <br>
<div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
</body>
</html>