> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Sent: Vendredi 30 Juillet 2021 16:52:23
> Subject: Minor improvement to anonymous classes
> 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 accommodate 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.)
About the proposed syntax, i'm not sure using '&' is a good idea, it may clash
with operators overloading if we allow them on primitive classes in the future.
(i believe the compiler may be able to differentiate between the two because of
the curly braces later but for a human it will be hard to make the difference
without precisely reading the code).
Philosophically, I think we should not add more features to inheritance,
inheritance is the goto of OOP, yes there are some corner cases where it's kind
a useful but at the same time you are pushing more people to discovering that
inheritance trees are a mess to maintain because the behavior is spitted to
several places and hard to refactor too.
new RedFoo() { + delegation } leads to a code easier to understand and easier
to maintain.
Rémi
