<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 26 Jan 2023, at 11:19, Maurizio Cimadamore wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">On 26/01/2023 18:16, Archie Cobbs wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">Yes, but for this to happen the subclass would have to be in effect intentionally subverting the superclass constructor.</p>
<p dir="auto">In other words, a problem like you describe can't suddenly just start happening "by accident" just because this new feature exists...</p>
</blockquote><p dir="auto">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.</p>
<p dir="auto">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.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Just to be clear:</p>
<p dir="auto">Early assignment to a <em>super</em> field is never possible,<br>
nor is any access other than <em>writing</em> a <em>local</em> field.<br>
No instance method calls to the uninitialized “this”,<br>
and no instance field reads of any kind from it, and<br>
no instance field writes to fields defined non-locally.</p>
<p dir="auto">Before the super-constructor call, the object cannot<br>
assume that super-class invariants have been set up,<br>
so no API point of the super-class can be touched,<br>
except to call a constructor.</p>
<p dir="auto">So the JVM doesn’t permit non-local early accesses (early<br>
meaning “before super constructor call”) because that<br>
would allow subclasses to inject actions into superclass<br>
state before the superclass initialization sequence.<br>
And that could, indeed, subvert invariants intended by<br>
the superclass author.</p>
<p dir="auto">But if a superclass sticks its nose into the business of<br>
a subclass, by down-casting, or by calling an overridden<br>
virtual from its constructor, then we must hope that the<br>
subclass has set things up so that the superclass sees<br>
something consistent. Archie’s proposals generally<br>
give subclass authors more freedom to set things up<br>
nicely before the super-constructor is called.</p>
<p dir="auto">That doesn’t lead to any increased subversion, only<br>
better control by the subclass of its proper concerns,<br>
by which I mean local concerns, in the same source file.</p>
<p dir="auto">I must be missing your point here Maurizio… There is<br>
some corner case you are concerned with but I can’t see<br>
where the danger is.</p>
<p dir="auto">— John</p>
</div></div></body>
</html>