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 <[email protected]>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 <[email protected] > > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
