Traits library

[Kam Kasravi]

Hi Brendan

Picking up where Tom left off below...   I've wondered how you and the ECMAScript body prefer to have 
particular concepts presented. Given that the lag time between new syntax and conformance across vendors 
could be months, years or never, it seems that there is always a need to provide a 'shim' 
or implementation that emulates proposed syntax. I think many concepts including Tom and Mark's
steer away from new syntax due to the problems noted.  In general should there be due diligence on both?
I realize this may vary per strawperson but thought you may have a general philosophy to share.

thx
kam



________________________________
From: Tom Van Cutsem <tomvc at google.com>
To: Brendan Eich <brendan at mozilla.com>
Cc: Mark S. Miller <erights at google.com>; es-discuss Steen <es-discuss at mozilla.org>
Sent: Thu, February 18, 2010 11:09:18 AM
Subject: Re: Traits library


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/20100219/f21d8453/attachment.html>