new function syntax and poison pill methods

Mark S. Miller erights at google.com
Fri Oct 26 13:06:36 PDT 2012


That makes sense. As I said, I'd be happy with #2 for both. But please
let's decide both questions together.


On Fri, Oct 26, 2012 at 12:46 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

>
> 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
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121026/5e91fe8e/attachment.html>


More information about the es-discuss mailing list