Traits library

[P T Withington]

On 2010-02-17, at 18:49, Tom Van Cutsem wrote:

> As a unit of code reuse, trait composition is more flexible than class
> inheritance.

+1

On 2010-02-17, at 19:30, Mark S. Miller wrote:

> Of the three, I would rather see Tom's traits than either my
> classes-as-sugar or Allan's extended object literal syntax.

+1

On 2010-02-18, at 00:29, Brendan Eich wrote:

> Add to this tax revolt the plain desire for better syntax-as-user-interface. If you want const f(){}, why //wouldn't// you want declarative trait syntax?

+1

On 2010-02-17, at 18:49, Tom Van Cutsem wrote:

> As a unit of classification, interface types are more flexible than class
> types (of course ES doesn't have interfaces, so I think a solid
> object-type-testing mechanism would be a more useful addition to ES than
> classes would be).

This seems like an important loose end to me.  If Harmony adopts a declarative trait syntax, is there still a reason to have an orthogonal type mechanism, rather than traits being types?