new function syntax and poison pill methods
brendan at mozilla.com
Sun Oct 28 15:13:15 PDT 2012
David Bruant wrote:
> If a property has been agreed on as non-configurable by TC39, there is
> certainly a good reason (because by default, everything agreed upon is
> configurable) and it has to be shipped as non-configurable from day
> one in my opinion.
Think about ECMA-262 as a library, the first and core library. Anyone
making an ES5 or later library may need to limit configurability,
writability, enumerability. How they do so is part of the API, their
library's contract with its users.
Libraries evolve. Popular libraries are constrained by backward
compatibility, although one can put up jquery-1.2.js and jquery-1.3.js
(or otherwise mix version into path part of URL) and satisfy both client
But the core library in the language VM is single-version or
unversioned. Especially with 1JS but even without it in view of the heap
shared by differently-versioned <script> elements.
This means we have to be dead-accurate in evolving the core library.
Propose carefully here and work for consensus in TC39,
prototype-implement in nightlies and even behind configurable
preferences or flags if that seems prudent, but since the goal is to
standardize, get enough implementor and user feedback to finalize the
new API or version, including any non-configurable properties.
It's not easy but I don't see a better alternative. So long as
implementors work from strawman-to-proposal Harmony specifications and
keep converging or else withdraw the new work, we should make progress.
Simpler and smaller is better, always. Mistakes in nightlies and/or
under flags can be corrected. Onward!
P.S. I like #2, which IIRC is Mark's preference too: any new or
strict-mode function form gets the poisoned pills. Then mixing new and
strict-old and non-strict-old function objects in the heap best helps to
smoke out bugs and reduces the number of case combinations.
More information about the es-discuss