Interfaces without implementation are like a day without sunshine

P T Withington ptw at pobox.com
Tue Oct 24 08:35:59 PDT 2006


On 2006-10-24, at 10:03 EDT, Dave Herman wrote:

>> Yes, we allow multiple inheritance of traits.  Our traits are the   
>> same as mixins, it just seems that trait is a more modern term
>
> I'm pretty sure this is false. Both terms are used in current  
> literature, and they are considered distinct. Naturally, there's a  
> lot of variation in the usage of each, so there aren't "universal"  
> definitions. But they aren't interchangeable, either.
>
> According to Fisher and Reppy:
>
> "Mixins are a mechanism designed to give many of the benefits of  
> multiple inheritance in single-inheritance languages. There are  
> strong similarities between traits and mixins, which are another  
> mechanism designed to address code sharing in single-inheritance  
> languages. The main difference between mixins and traits is that  
> mixins force a linear order in their composition. This order avoids  
> the complexities of the diamond property, but it makes mixins a  
> more fragile mechanism."
>
> [http://people.cs.uchicago.edu/~jhr/papers/2004/fool-traits.pdf]
>
> Now, I have never seen traits with fields before. All the  
> literature I've seen motivates traits as "pure units of behavior"  
> and disallow instance variables. For example, according to  
> Nierstrasz et al:
>
> "Traits bear a superficial resemblance to mixins, with several  
> important differences. Several traits can be applied to a class in  
> a single operation, whereas mixins must be applied incrementally.  
> Trait composition is unordered, thus avoiding problems due to  
> linearization of mixins. Traits contain only methods, so state  
> conflicts are avoided..."
>
> [http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf]
>
> Based on your description, it sounds like what you have implemented  
> is order-sensitive and allows fields. So what you have sounds like  
> mixins, not traits.

I admit to not being aware that 'trait' had been staked out as you  
describe above.  We have been using the term more in line with the  
dictionary definition.  If trait is defined as not permitting state  
or overriding, then, yes, we have implemented mixins.  Using the  
definitions you cite, interfaces << traits << mixins.  Traits remove  
state (and in some cases overriding) from mixins, interfaces remove  
behavior from traits.  Or, looking at it another way, traits and  
interfaces take power away from the programmer in the belief that the  
programmer will only hurt themselves.  Where does es4 want to stand?




More information about the Es4-discuss mailing list