<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 11/06/2024 16:28, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxvum=vM1TTw=PDPYBYxPjkjLWGhag_no7sAYHA3L8rBug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Tue, Jun 11, 2024 at 3:53 AM Maurizio
Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div> So, back to Attr - turns out that this code (of
which I’m not very proud of :-) ), can be rewritted
w/o accessing chk.basicHandler inside the anon class.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Sure, you could do that - but that's really beside the
point.</div>
<div><br>
</div>
<div>The point I'm making is simply to show that incidences of
classes declared in early construction contexts accessing
outer instances exist out there in the world. They may be
rare, but they are not so rare that they can be dismissed -
at least not according to the high Java/openjdk backward
compatibility standards that I've observed over the years.
Do you disagree?<br>
</div>
</div>
</div>
</blockquote>
<p>I think so. At times we have made other source incompatible
changes (esp. in the context of type inference in Java 8) with the
goal of putting the language on a firmer ground.</p>
<p>So far the evidence is that this code idiom is basically
non-existent in the wild, and there's workarounds. So that, alone,
wouldn't constitute a great argument IMHO.</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CANSoFxvum=vM1TTw=PDPYBYxPjkjLWGhag_no7sAYHA3L8rBug@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Thinking more, I think I can perhaps find an argument
in defense of the strategy of the approach outlined in
the current JEP: migrating lambdas to classes.
<p style="margin:0px 0px 1.2em">So, back to your
example:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);display:block;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248)"><span><span style="color:rgb(51,51,51);font-weight:bold">class</span> <span style="color:rgb(68,85,136);font-weight:bold">Outer</span>
<span style="color:rgb(68,85,136);font-weight:bold">int</span> <span style="color:rgb(68,85,136);font-weight:bold">x</span></span>;
<span><span style="color:rgb(51,51,51);font-weight:bold">class</span> <span style="color:rgb(68,85,136);font-weight:bold">Inner</span> <span style="color:rgb(51,51,51);font-weight:bold">extends</span> <span style="color:rgb(68,85,136);font-weight:bold">Foo</span> </span>{
Inner() {
<span style="color:rgb(51,51,51);font-weight:bold">super</span>(<span style="color:rgb(51,51,51);font-weight:bold">new</span> Bar() {
{ Outer.<span style="color:rgb(51,51,51);font-weight:bold">this</span>.x++; } <span style="color:rgb(153,153,136);font-style:italic">// allowed???</span>
});
}
}
}
</code></pre>
<p style="margin:0px 0px 1.2em">Let’s say we write this
using lambdas:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);display:block;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248)"> <span><span style="color:rgb(51,51,51);font-weight:bold">class</span> <span style="color:rgb(68,85,136);font-weight:bold">Outer</span>
<span style="color:rgb(68,85,136);font-weight:bold">int</span> <span style="color:rgb(68,85,136);font-weight:bold">x</span></span>;
<span><span style="color:rgb(51,51,51);font-weight:bold">class</span> <span style="color:rgb(68,85,136);font-weight:bold">Inner</span> <span style="color:rgb(51,51,51);font-weight:bold">extends</span> <span style="color:rgb(68,85,136);font-weight:bold">Foo</span> </span>{
Inner() {
<span style="color:rgb(51,51,51);font-weight:bold">super</span>(() -> { ... Outer.<span style="color:rgb(51,51,51);font-weight:bold">this</span>.x++ ... });
});
}
}
}
</code></pre>
<p style="margin:0px 0px 1.2em">This is now ok, as the
lambda has access to any enclosing instances that were
available at the time the lambda was created (e.g.
Outer.this). </p>
</div>
</div>
</blockquote>
<div>I'm not sure I understand... I don't see how an inner
class vs. a lambda are any different with respect to how
outer instances are handled or can be accessed. In both
cases, the constructor is going to have to construct some
object and pass as a synthetic parameter a copy of the
synthetic "Outer.this" parameter provided to the Inner()
constructor. In neither case can the constructor pass the
Inner "this" instance at that time, because it is still
uninitialized.<br>
</div>
</div>
</div>
</blockquote>
<p>I don't want to dive in the specifics on how things are
implemented, which is beyond the point I was making.</p>
<p>My point is that we'd probably want the two examples above to
align, which probably means going with the rules in JEP 482 (or
some alternate rules which achieve the same effects).<br>
</p>
<p>Maurizio<br>
</p>
</body>
</html>