Loosening requirements for super() invocation

Archie Cobbs archie.cobbs at gmail.com
Wed Jan 25 19:06:33 UTC 2023


On Wed, Jan 25, 2023 at 12:49 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Thinking more on this -- I think there is significant simplicity dividend
> here if we relax our goals a little bit.  Supporting constructs such as
>
>         if (bar)
>             this(f(bar));
>         else
>             this(g(bar), 0);
>
> would require a full DA/DU analysis, but if the goal is really "allow
> statements before the this/super", we can get by with a considerably
> simpler feature.
>

Ugh - to be honest I really don't like this simplification. For example, it
invalidates two of the five "housekeeping" examples in the current JEP
draft ("choosing constructor at runtime" and "complex preparation").

The idea of superclass initialization working just like blank final field
initialization is familiar and intuitive... and the implementation is
straightforward to piggy-back on existing DU/DA dataflow analysis.


> This brings the spec footprint down considerably, while still eliminating
> complex/risky workarounds around "super first".
>

I agree that we need to think carefully about how to best update the spec.
But I'm not ready to give up yet on the original plan...

Put another way, if a reasonable language change is such a problem for the
spec, then that's a problem to solve with the spec, not the language.

Now I'm not a spec expert (it seems kind of analogous to being a patent
lawyer) but what about this plan:

   1. "Piggy-back" superclass initialization DA/DU on top of the existing
   spec for blank final fields - however you want to word that...
   2. Specify that for any statement in a constructor:
      1. If:
      1. Superclass initialization is not DA at the beginning of the
         statement
         2. The statement would not be legal in a static context
      1. Then:
         1. The statement is illegal, unless:
            1. The statement is an assignment statement and the LHS of the
            statement is a non-static field of the new instance

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230125/2f3ef732/attachment-0001.htm>


More information about the amber-dev mailing list