Loosening requirements for super() invocation

[Brian Goetz]

I think that's where we should start; if we are spectacularly 
successful, we can come back for more.

On 1/26/2023 5:46 PM, Archie Cobbs wrote:
> On Thu, Jan 26, 2023 at 4:05 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     On 26/01/2023 21:37, Maurizio Cimadamore wrote:
>     > For instance, even if we only allow updates to local fields, an
>     > instance initializer can now see these updates. for you, this is
>     > something good, for me this is just something else that developers
>     > would have to remember about initialization order.
>     >
>     Also, thinking some more, I realized that one of the things I find
>     more
>     "offputting", is that putting initialization of instance fields
>     before
>     `super` violates the mental barrier I have (and that I'm sure other
>     developers have too) that the letters `t h i s` should never appear
>     before a super() invocation. And I know it's an assignment, and it
>     special, and the VM can deal with it... but... still...
>     language-wise I
>     think if we can latch onto rules that are fairly simple to explain
>     ("no
>     `this` -explicit or implicit - before this point!!!!), it makes
>     things
>     easier.
>
>
> Well I agree with that sentiment... having a simpler mental model is 
> always nicer.
>
> Personally as a developer I would gladly trade that simpler mental 
> model for the warm & secure feeling I'll get when I can KNOW that my 
> final fields are taken care of, before anything else can possibly go 
> wrong with them (maybe restrict to only assignments to local final 
> fields?). And the only people likely to venture into the 
> init-before-super territory are the ones who actually need it... and 
> they will need it badly... the rest of the crowd can keep super() 
> first and keep their model nice & simple. It's kindof like 
> ThreadLocals - you'll know when you need one, and when you do you'll 
> be glad they're there because you realize there's no other way; but 
> until then, you have no need to worry or even know about them.
>
> Anyway it sounds like - unless John Rose wants to pick up the fight? - 
> the sentiment here is to only include Brian's item #1, i.e., to allow 
> only purely "static context" code prior to what is to remain a single 
> super()/this() call. I think this is being too conservative but that's 
> just my one opinion.
>
> Do we have official agreement on this? I'm happy to keep arguing if not :)
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/1cfaca03/attachment-0001.htm>