new function syntax and poison pill methods

Brendan Eich brendan at
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 mailing list