[External] : Re: JEP 447 Statements before super() - Preview feature?

Archie Cobbs archie.cobbs at gmail.com
Fri May 19 01:36:49 UTC 2023


Hi Alex,

Thanks for your thoughtful review & comments.

-Archie

On Thu, May 18, 2023 at 6:53 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Hi Archie,
>
> Your updates to the JEP are excellent in every way. Thank you.
>
> Alex
>
> On 5/18/2023 3:56 PM, Archie Cobbs wrote:
> > Hi Alex,
> >
> > Great comments, thanks....
> >
> > On Thu, May 18, 2023 at 2:25 PM Alex Buckley <alex.buckley at oracle.com
> > <mailto:alex.buckley at oracle.com>> 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
> >     <
> https://urldefense.com/v3/__https://stackoverflow.com/a/285187__;!!ACWV5N9M2RV99hQ!O-9cBnMpSBttTFUwyTA_mphXNEnUrb691HNu5nTJkieZQZMkA1UgNTyTpWa05uE-RnIz8ZnI_-8soiSv_GkKYHs1Sw$>).
> 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
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230518/e32270e7/attachment-0001.htm>


More information about the amber-spec-experts mailing list