Traits library

[David Herman]

First, this traits proposal looks very nice -- thanks, Tom and Mark, for your work on this.

I want to add another point about the benefit of new syntax by calling out a piece of the code.google.com proposal under "Performance," where it says: "In order for the partial evaluation scheme to work, programmers should use the library with some restrictions." This is one of the places where you have the opportunity to call out more precisely in the language where users can expect better performance. By creating a declarative syntax, you invite implementors to make the common cases efficient, and provide a clearer set of rules for programmers to know when they are or aren't straying into "you can do that, but it'll cost you" territory.

Another side of the same coin is that you /dis/invite users from accidentally straying into the expensive territory. The convenient syntax provides an incentive for people to use the version you want to be the common case.

On Feb 19, 2010, at 7:29 AM, Kam Kasravi wrote:

> 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.

I know your question was to Brendan, but if I may add my $.02: we should be mindful but not terrified of changing the language. That's what we're here to do, after all!

Now, the specific concern over new syntax has been that it prevents a program from even running, which means you can't dynamically test for a feature before using it. Putting aside the fact that you could use `eval' (or dynamic module loading, given a module system) for such a purpose, I'm still not sure how often people actually want to build two different implementations of a program based on whether or not a particular feature exists. We shouldn't hold back the language just because it'll take take for new features to be spread enough for commonplace use. That's all the more reason to move forward sooner than later.

That said, I think something like the traits library could have a nice migration path, where a library compatible with ES5 could be even more attractive down the road with new syntax.

Dave