Interfaces without implementation are like a day without sunshine

P T Withington ptw at
Thu Aug 24 13:21:25 PDT 2006

On 2006-08-24, at 14:19 EDT, Jeff Dyer wrote:

> The hard requirement for interfaces (when they were conceived in  
> AS3 at
> Macromedia/Adobe) was to be able to relate a class to one or more
> "abstract" types (as in Java). We discussed a richer idea of  
> interfaces
> that would allow add implementation, etc, but were forced by design  
> and
> practical concerns to choose a minimalist solution that would allow  
> for
> future growth.

We have an implementation of 'traits' (composable units of behavior)  
that can be built on es3.  We have found them to be useful for  
structuring complex systems.  There are plenty of precedents for this  
pattern in O-O languages, although neither Java nor C# chose to adopt  
it -- perhaps for the same reasons.  I'm suggesting we move beyond  
the Java straight-jacket...

> But how do interfaces related to traits? To quote your reference
> ( "Unlike mixins and
> multiple inheritance, Traits do not employ inheritance as the
> composition operator. Instead, Trait composition is based on a set of
> composition operators that are complementary to single inheritance and
> result in better composition properties."

While we are using the term 'trait' for our system, our  
implementation is more along the lines of mix-ins (as described in  
their paper 
Scha03aTraits.pdf).  We allow a class to be composed of a base class  
and any number of traits.  The class is implemented by creating a  
prototype linked through its [[proto]] to instances of each of the  
traits and finally the base class.  So our traits are order- 
sensitive, they are composed by inheritance and you can override  
methods in traits (and access the overridden method using super).  We  
have not found it necessary to adopt the 'new composition method' of  
the referenced paper.  Although I understand from personal experience  
their concerns about mix-ins (ordering, integration, and fragility),  
I'm not convinced their solution is anything more than an enforced  
programming style.

We also allow state in our traits (as Nicholas requested).

More information about the Es4-discuss mailing list