Traits library

[Tom Van Cutsem]

>
> Put together the user and implementor taxes, and you have sufficient cause
> for new syntax.
>
> 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?


Hi Brendan,

Thanks for enlightening us with the implementation-level issues involved in
getting user-land traits optimized. That definitely puts things in
perspective. I wholeheartedly agree that dedicated syntax would be of great
help to users, and to implementors as a not-to-be-underestimated bonus.

I am not at all opposed to dedicated syntax/semantics for traits in
ES-harmony. Think of traits.js more as an exercise in exploring the design
space of what is possible today. For example, the fact that ES5's property
descriptor maps turned out to be directly usable as traits was a surprising
new insight to me.

I think the most useful outcome of this experiment is that it gives us a
better idea of what the fundamental limits of a library approach are. For
example: that syntax for traits is (mostly) not a boilerplate issue but a
semantic issue (early error feedback) + an implementation issue (method
sharing).

And who knows, if there is an uptake of this library in ES5, it would help
familiarize programmers with traits without them having to wait for
dedicated syntax. But I am aware that this is very optimistic: many have
previously designed good class, mixin and even trait libraries for ES3, and
to the best of my knowledge, none of these seem to have widely caught on.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100218/18ce1f8f/attachment.html>