May 24-26 rough meeting notes

Thaddee Tyl thaddee.tyl at gmail.com
Mon May 30 01:54:32 PDT 2011


On Mon, May 30, 2011 at 6:55 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote:
>> ... I believe that, given the fact that browsers will implement
>> ES.next incrementally, we should find a way to allow graceful
>> fallback, rather than version-driven conditionals.
>
> This is trivial for new global object properties, but such additions in the
> past, even including JSON, have been breaking changes for some web sites.

They have coped with that by using polyfills such as:

  if (!this.JSON) {
    this.JSON = {};
    ...
  }

> With the module system in ES.next we are probably instead going to add
> standard modules named by anti-URI module resource locators such as "@name",
> and thereby avoid polluting the global object, or even the Object
> constructor.
> But say we do add, e.g. Object.createPrivateName(name, visible). That will
> be detectable using good old "object detection" -- no need for a "features"
> object as you show.
>
>
>> The fact that Harmony features are already batched up makes this easy;
>> maybe we can use a different use-pragma that already defined.
>> Something like an object literal. Object literals are so cool.
>> if (features.es6.proxies) {
>
> How is this better or different from any version-driven conditional? It's
> not, at least not up until the second dot.
>
> Authors will want to object-detect APIs expressed as built-in objects, but
> other features including new syntax cannot be handled easily or at all that
> way, and many authors will want the whole pie.
>
> /be


In the current Harmony proposals, there are as many "syntax breakers"
(with which current js parsers fire a syntax error) as there are "soft
breakers" (which allow graceful degradation). Syntax breakers include
things like "let", "const", destructuring, parameter default values,
rest parameters, spread, modules and generators. Those are the syntax
errors. Soft breakers include proxies, weak maps, egal, proper tail
calls, binary data, Number, String, Function and Math improvements,
typeof null and completion reform. These, on the other hand, can be
feature-detected.

For most of the soft breakers, people will *definitely* want to check
for implementation backing. For things like proper tail calls, feature
detection can mean performance tuning; for typeof null it means that
we can make sure that, in all cases, our code won't break.

For the syntax breakers, however, browsers will, indeed, have to
implement all those features in one shot. They cannot do it
incrementally, or else ES.next-only code may very well break.

What do you think? Should we force browser vendors to implement
soft-breakers in one shot too, even though we could let them do it one
feature at a time via feature detection?


More information about the es-discuss mailing list