Minor improvement to anonymous classes

[Éamonn McManus]

I would like to suggest that the proposal would be more consistent with the
cited precedents if the &-clauses were before the parens rather than after.
Instead of this:

new AbstractFoo(args) & RedFoo {...}

we would have this:

new AbstractFoo & RedFoo(args) {...}

That would also be less garden-pathy. If we compare this:

if (x == new AbstractFoo(args) & RedFoo & BlueFoo {...}) {...}

with this:

if (x == new AbstractFoo(args) & condition1 & condition2) {...}

we see that the parser would have to scan ahead to the { in order to see
that this is an anonymous-class-with-interfaces rather than a
named-class-followed-by-conditions. (Human readers would be clued in by the
capitalization of the type names but that's not part of the grammar.)

On Fri, 30 Jul 2021 at 07:53, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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:
>
>      interface Foo { ... lots of stuff .. }
>      abstract class AbstractFoo { ... lots of base implementation ... }
>
>      interface RedFoo extends Foo { void red(); }
>
> 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.
>
> We already address this problem elsewhere; there are several places in
> the grammar where you can append additional _interfaces_ with &, such as:
>
>      class X<T extends Foo & Red> { ... }
>
> and casts (which can be target types for lambdas.)
>
> 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:
>
>      new AbstractFoo(args) & RedFoo { ... }
>
> This would also smooth out a rough edge refactoring between lambdas and
> anonymous classes.
>
> I suspect there are one or two other places in the spec that could use
> this treatment.
>
> (Note that this is explicitly *not* a call for "let's do full-blown
> intersection types"; this is solely about class declaration.)
>
>
>