It seems reasonable: If you can do this for lambdas,
which are (sort of) a concise anonymous inner class
notation, you should be able to do this with the next
level of notation, anonymous inner classes. It’s
ungraceful to have MI on lambdas and named inner
classes, but not the intermediate notation.
Any similar limitations to consider loosening at this time?
Are there things with generics you can do with lambdas
and named ICs but not AICs?
> On Jul 30, 2021, at 7:52 AM, Brian Goetz <brian.go...@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.)
>
>
