<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Your proposal is for anon classes, which I think works well.</p>
<p>One related case I found quite often is the desire to combine
types e.g. in a return type:</p>
<p>Foo & AutoCloseable getCloseableFoo();</p>
<p>This veers into declaration-land, visible to javadoc and all. So
it probably doesn't have a good benefit vs. cost ratio. Also, this
is effectively adding intersection types (I don't think
restricting at return types only will be feasible).<br>
</p>
<p>But I'm puzzled by the fact that programmers can, in a way, do
something similar to the above with a generic method:</p>
<p><X extends Foo & AutoCloseable> X getCloseableFoo();</p>
<p>Which kind of works, but it's quite an horrible hack (you
introduce a type parameter you don't need - which means compiler
will try to infer types, etc.)</p>
<p>I'm not suggesting we have to solve this - just wanted to make
sure this was somewhere on the radar.</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 30/07/2021 15:52, Brian Goetz wrote:<br>
</div>
<blockquote type="cite" cite="mid:424ad976-6f0c-5ada-ca22-f5a3d9c76dc1@oracle.com">
<font size="+1"><font face="monospace">I have been working on a
library where I've found myself repeatedly refactoring what
should be anonymous classes into named (often local) classes,
for the sole reason that I want to combine interfaces with an
abstract base class:<br>
<br>
interface Foo { ... lots of stuff .. }<br>
abstract class AbstractFoo { ... lots of base
implementation ... }<br>
<br>
interface RedFoo extends Foo { void red(); }<br>
<br>
and I want a factory that yields a RedFoo that is based on
AbstractFoo and implements red(). Trivial with a named class,
but there's no reason I should not be able to do that with an
anonymous class, since I have no need of the name. <br>
<br>
We already address this problem elsewhere; there are several
places in the grammar where you can append additional
_interfaces_ with &, such as:<br>
<br>
class X<T extends Foo & Red> { ... }<br>
<br>
and casts (which can be target types for lambdas.)<br>
<br>
These are not full-blown intersection types, but accomodate
for the fact that classes have one superclass and potentially
multiple interfaces. It appears simple to extend this to
inner class creation expressions:<br>
<br>
new AbstractFoo(args) & RedFoo { ... }<br>
<br>
This would also smooth out a rough edge refactoring between
lambdas and anonymous classes. <br>
<br>
I suspect there are one or two other places in the spec that
could use this treatment.<br>
<br>
(Note that this is explicitly *not* a call for "let's do
full-blown intersection types"; this is solely about class
declaration.)<br>
<br>
<br>
</font></font> </blockquote>
</body>
</html>