Minor improvement to anonymous classes

Tagir Valeev amaembo at gmail.com
Sat Jul 31 03:44:40 UTC 2021


I support this suggestion. I stumbled upon this problem many times.
Kotlin allows such declarations [1]
object : AbstractFoo(args), RedFoo {...}
Seems there's no conceptual difficulties with this enhancement.

With best regards,
Tagir Valeev.

[1] https://kotlinlang.org/spec/expressions.html#object-literals

On Fri, Jul 30, 2021 at 9:53 PM 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.)
>
>


More information about the amber-spec-experts mailing list