Must you `override` when implementing an interface?

Jeff Dyer jodyer at
Mon Mar 26 11:48:55 PDT 2007

> From: P T Withington [mailto:ptw at]

> >> The question came up in the context of documenting methods,
> >> distinguishing methods that are being defined in the class (and are
> >> not part of an interface).  In that sense, an `implement` attribute
> >> would have some of the benefit of `override` in catching type-ohs:
> >> the compiler could signal an error if you define a method as
> >> implementing an interface and there is no matching interface.
> >
> > It already does. In AS3/draft-ES4 it is a static error if any of the
> > inherited interface methods is not implemented in the inheriting
> > class,
> > unlike in Java. Partially implemented (or abstract) classes don't
> > exist
> > in ES4.
> I'm considering the case where I define a method that I think is part
> of an interface but it is not:
> interface A {
>    function x ();
> }
> class B implements A {
>    function x () {...};
>    function y () {...};
> }
> function (a:A) {
>    a.y();
> }
> Possibly unlikely, and yes, you get an error at the call site, but if
> I had to say:
> class B implements A {
>    implement function x () {...};
>    implement function y () {...};
> }
> The compiler could warn me that there is no interface method `y` in
> the interfaces implemented by B.  Perhaps useful in an IDE or where
> separate compilation is going on?  I'm comparing that to the override
> case where I declare a method as being an override but there is no
> such method in the super chain.

This only solves part of the problem. What if B also implements an
interface 'Z' that has a 'y' method? The program is still exposed to the
same kinds of errors. I actually prefer a system where you have to
declare the interface in which the implementing method was introduced.
For example,

interface A {
   function x ();

class B implements A {
   A function x () {...};
   A function y () {...};   // oops error, no y in A

But that proposal did not get traction in TG1. I could try to
resuscitate it if there are new, compelling real world use cases.

The point is to avoid name confusion (ambiguity and misnaming) when
implementing multiple interfaces. As it is, any 'public' method will
implement an inherited interface method with the name and compatible

Use cases anyone?


More information about the Es4-discuss mailing list