<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 26/01/2023 16:12, 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>
</div>
</blockquote>
Thanks<br>
<blockquote type="cite" cite="mid:CANSoFxtqE=fbU7qWPd6i=uiw2RJEzONFVj5fQjyuT4WA6=dMUw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
<br>
</div>
</div>
</blockquote>
<p>I agree that the behavior you propose is not problematic per se.</p>
<p>But, as I mentioned, it brings up can of worms. For instance, now
a superclass constructor could see its field with a non-zero
value. Which could definitively be surprising. After all, there
might be code in the wild assuming that an int field that has not
been assigned yet has value zero - whether writing code like that
is good or bad, it's a separate question. My point here is that
here you cross a fine line between "let's make the language more
expressive" and "this change might have some compatibility
impact".<br>
</p>
<p>As I said, my general feeling is that it's not worth going there
to "fix escaping this" - because... developers should strive to
write code where this doesn't escape in the first place (and
hopefully the Lint warning you recently added will help with
that).</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:CANSoFxtqE=fbU7qWPd6i=uiw2RJEzONFVj5fQjyuT4WA6=dMUw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</body>
</html>