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 <to...@google.com>
To: Brendan Eich <bren...@mozilla.com>
Cc: Mark S. Miller <erig...@google.com>; es-discuss Steen <es-discuss@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
