Hi Alex, Great comments, thanks....
On Thu, May 18, 2023 at 2:25 PM Alex Buckley <[email protected]> wrote: > ... the Non-Goals should focus on what the end user (a developer) will > see or not see. Finally, almost no-one will be able to figure out what > this means -- "There are many ways in which the interplay between > superclass constructors and subclass initialization might be improved" > -- so please either explain (in a very small space) or remove. > Agreed - removed. I'm saying that millions of lines of code exist because people explicitly > coded around the restriction you're now removing, so there's a huge > amount of refactoring that is (a) possible and (b) desirable, so we > _assume_ that static analyzers and IDEs will promote this refactoring to > their users. If you don't say this in the JEP, no-one will know it. > No-one knows as much as you about this feature, so please share :-) > Good point.. I've added some more verbiage to Risks & Assumptions. 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. So hopefully that is a big hint to any tool providers that they already know how to treat the code in the constructor prologue. > I would like to enrich the "Implementing fail-fast" subsection by > acknowledging the fine idiom of _telescoping constructors_, where > simpler constructors delegate to richer constructors by using `this(..)` > to pass default arguments (see https://stackoverflow.com/a/285187). In > any intermediate constructor of non-zero arity, being able to check the > arguments before delegation could be useful. > "Telescoping constructors" is definitely a worthy use case for this feature... I like that and have added it. And a good real-world example comes from none other than java.lang.Thread. -Archie -- Archie L. Cobbs
