Traits library

[Brendan Eich]

The proposals, including from Tom and Mark, don't steer away from  
const f() {} and other new syntax (destructuring).

Harmony has new syntax, this is not an open issue. As we've discussed  
over the years, the language's users deserve new syntax, particularly  
for early error reporting. Implementors also benefit.

One answer for the installed base problem is for the server to detect  
downrev browsers and send them content translated automatically to  
target ES3, even ES3 with workarounds (e.g. for IE's named function  
expression binding pollution bug).

The other extreme is to hold off on using the new syntax for five  
years, give or take. This can be a problem, but it's easy to  
exaggerate it, and to use past monopoly behavior to predict outcomes  
in a non-monopoly future.

An example: IE4 had regexps close enough to match Netscape 4.x, but  
IE4 lacked not try/catch/finally, so regexps were usable sooner cross- 
browser, but try/catch/finally was not usable till more recently.

This example in full, regexps and try/catch/finally, shows how the  
situation depends on how fast browser vendors (a) implement new  
features; (b) upgrade their installed bases -- (b) is critical not  
only for developers, but primarily to protect users by fixing old  
security bugs.

Content authors will have to decide among the several solutions. The  
JS community should and no doubt will make translation tools available  
(even in-browser translators, where feasible).

But we will not freeze syntax.

/be

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

> 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/8518274b/attachment-0001.html>