Loosening requirements for super() invocation

[Archie Cobbs]

On Thu, Jan 26, 2023 at 1:19 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 26/01/2023 18:16, Archie Cobbs wrote:
>
> On Thu, Jan 26, 2023 at 11:00 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> I agree that the behavior you propose is not problematic per se.
>>
>> But, as I mentioned, it brings up can of worms. For instance, now a
>> superclass constructor could see its field with a non-zero value. Which
>> could definitively be surprising. After all, there might be code in the
>> wild assuming that an int field that has not been assigned yet has value
>> zero - whether writing code like that is good or bad, it's a separate
>> question. My point here is that here you cross a fine line between  "let's
>> make the language more expressive" and "this change might have some
>> compatibility impact".
>>
> Yes, but for this to happen the subclass would have to be in effect
> intentionally subverting the superclass constructor.
>
> In other words, a problem like you describe can't suddenly just start
> happening "by accident" just because this new feature exists...
>
> Well, you could have a subclass (in some client jar) which "subverts" as
> you say, some superclass in a library. Perhaps the library was not prepared
> for that kind of behavior, and now there's a new bug.
>
> IMHO, we should try to stay well clear of that can of worms. It's not like
> we have to open it now either - the other things you propose are 100%
> non-controversial.
>

So what do you think then of only allowing access to *local* fields prior
to super()?

Seems like this draws the boundary more tightly around the functionality
we're actually aiming for, and keeps out the wormy stuff.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/12f5c54d/attachment.htm>