<div dir="ltr">Hi Alex,<br><div dir="ltr"><br></div><div>Great comments, thanks....<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 18, 2023 at 2:25 PM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@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">... the Non-Goals should focus on what the end user (a developer) will <br>
see or not see. Finally, almost no-one will be able to figure out what <br>
this means -- "There are many ways in which the interplay between <br>
superclass constructors and subclass initialization might be improved" <br>
-- so please either explain (in a very small space) or remove.<br></blockquote><div><br></div><div>Agreed - removed.<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">I'm saying that millions of lines of code exist because people explicitly <br>
coded around the restriction you're now removing, so there's a huge <br>
amount of refactoring that is (a) possible and (b) desirable, so we <br>
_assume_ that static analyzers and IDEs will promote this refactoring to <br>
their users. If you don't say this in the JEP, no-one will know it. <br>
No-one knows as much as you about this feature, so please share :-)<br></blockquote><div><br></div><div>Good point.. I've added some more verbiage to Risks & Assumptions.</div><div><br></div><div><div> I also added some language to highlight the fact that this 
"pre-construction" context we are creating is not really new - the rules are the same as already apply to the this()/super() parameter expressions.</div><div><br></div><div>So 
hopefully that is a big hint to any tool providers that they already know how to treat the code in the constructor prologue.<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would like to enrich the "Implementing fail-fast" subsection by <br>
acknowledging the fine idiom of _telescoping constructors_, where <br>
simpler constructors delegate to richer constructors by using `this(..)` <br>
to pass default arguments (see <a href="https://stackoverflow.com/a/285187" rel="noreferrer" target="_blank">https://stackoverflow.com/a/285187</a>). In <br>
any intermediate constructor of non-zero arity, being able to check the <br>
arguments before delegation could be useful.<br></blockquote><div><br></div><div>"Telescoping constructors" is definitely a worthy use case for this feature... I like that and have added it.</div><div><br></div><div>And a good real-world example comes from none other than java.lang.Thread.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">-Archie</div><div class="gmail_quote"><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>