Must you `override` when implementing an interface?

Jeff Dyer jodyer at
Mon Mar 26 16:22:16 PDT 2007

From: peterjoel at [mailto:peterjoel at] On Behalf Of

> But I think there would be some complications around having a method
> be part of multiple interfaces (unless a method could be declared in
> multiple namespaces).

In this case, we would do as we do today and use 'public' to mean
implements all unimplemented, matching methods with the same identifier.

> Could there also be a complication with the necessity of having to
> have the namespace automatically opened within any scope that
> references a variable typed as either the interface or implementing
> class?

Our thinking early in the development of AS3 was to open only an
interface's namespace when,

* referencing through a property annotated with that interface or 
  through an interface or class that inherits from that interface, and
* inside the body of a method that implements a method of that 

	interface I { function m() }
	interface J { function m() }
	class A implements I, J { 
          I function m() { n() }   // calls I::n
	    I function n() { }       
	    J function m() { n() }   // calls J::n
          J function n() { }

	var a : A = new A
	a.m()      // error: ambiguous reference
	a.I::m()   // calls I::m
      a.J::m()   // calls J::m

	var i : I = a
	var j : J = a
	i.m()	     // calls I::m
      j.m()      // calls J::m

Ihe big idea here is that an interface describes a view of an object. To
use that view you need to ask for it, either with a type annotation or a
namespace qualified identifier. "use namespace I" is not allowed, nor
was any other way of opening an interface namespace.

This is not what happened though. Some users were not comfortable with
the "interface as namespace" idea and wanted to be able to implement
interface methods to be in the 'public' namespace so they could be
accessed through any ordinary reference without namespace qualification.

So our next step was to say that you can implement interface methods
with methods in the 'public' namespace. References through the interface
would see them as an interface method, and other references could see
them as a public method. This sounded pretty promising, but it was
starting to get complicated. Interface methods could be in two
namespaces (a first in our naming scheme), and the logic for determining
which interface methods get implemented by which public method
declarations when you have multiple base interfaces and a base class
that implements some of those interface methods (I'll spare you the
details for now) was getting hairy.

Out of time and energy we rolled the design of interfaces in AS3 back to
a simpler and I think future proof system where interface methods are
implemented by compatible public methods. Such methods might implement
any number of interface methods inherited by its class. This might lead
to conflicts that can only be resolved in the interfaces, but oh well.

I'm writing all of this in case it of general interest, and also because
most of the TG1 workers haven't heard it all, and just in case we made a
mistake with AS3, and should press on to a more expressive interface
system for ES4.



More information about the Es4-discuss mailing list