new function syntax and poison pill methods

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Oct 26 12:46:42 PDT 2012


On Oct 26, 2012, at 12:29 PM, Mark S. Miller wrote:

> Let's resolve this the same way as another open question left over from ES5: What about the built-in functions? These are neither strict nor non-strict, so ES5 is silent on whether they have these poisoned properties. This oversight has caused us tremendous pain in SES, as seen by searching for "caller" and "arguments" in <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js>. (93 and 50 hits respectively, most of which I believe are relevant.) At one point, browsers had ES5 conforming behavior that made them insecurable. Fortunately, the modern versions of all major browsers now have conforming and securable behavior, but this was achieved by side conversations outside the standards process. Now that it has been achieved without breaking the web, we are free to standardize a securable behavior.
> 
> For built-in functions, I think the best answer is #2. Since built-ins are neither strict nor non-strict, #1 does not apply. #3-prime (defined below) is IMO inferior to #2 for catching bugs in old code, but the fact that modern browsers did not break the web perhaps indicates that we no longer need to worry about those bugs.
> 
> For new function forms, which is best should be decided together with the built-ins. If the built-ins go with #2, the new function forms should probably go with #1, though #2 would be acceptable. If built-ins go with #3-prime, new function forms should probably also go with #3-prime.
> 
> #3-prime is, of course, that we mandate that implementors not provide such insecurable magic. #3 as is is unacceptable, because the spec would be inadequate to reason about the security of a SES-for-ES6. If we can't agree on #3-prime, then let's agree not to do #3.

thanks for bring up the built-ins. 

For the new forms, I'd prefer #2, I believe that for ES5 we rationalized that we could place the poison pill restriction on strict function because such functions didn't exist in prior editions and hence introducing the poison pills on such new features could not introduce any (direct) compatibility issues for existing code.  The same logic would seem to apply to any new syntactic forms for functions that we add in ES6. From a compatibility perspective it should be safe to give them all poison pill properties.

Allen

> 
> 
> On Fri, Oct 26, 2012 at 10:37 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> ES5 added "poison pill" properties to the strict mode function objects that were intended to prevent implementors from supporting the non-standard legacy "caller" and "arguments" properties on such objects.
> 
> In ES6 we have several new syntactic forms for defining functions: arrow functions, concise methods, generators.  What should be do WRT the position pill properties for functions defined using such new syntax.  Possibilities:
> 
> 1)  Same as ES5 function definitions.  If strict they get the poison pills , if non-strict they don't.
> 2)  All new function forms always get poison pills, even if they aren't strict.
> 3)  They never get poison pills because new implementor would be silly enough to associate they legacy features with new syntax.
> 
> Options 1&2 would essentially collapse to "always" if new function definition syntactic forms always produced strict mode code.  However, I believe, the current plan of record is that the new forms have the same strict mode opt-in rules as ES5 uses for function definitions.
> 
> Allen
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121026/d3eb36bb/attachment-0001.html>


More information about the es-discuss mailing list