> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Waldemar Horwat > Sent: 31. mars 2008 18:03 > To: es4-discuss@mozilla.org > Subject: Strict mode recap > > Here are the items mentioned for inclusion in strict mode: > > - Don't turn a null 'this' value into the global object (if > non-strict mode in ES4 doesn't already do this) > - Throw on writes to read-only properties > - Throw on deletes of dontdelete properties > - delete o.x when x is not in o but in the proto will throw
Actually delete o.x when x is not an own property on o, regardless of whether x in o. > - Reference before definition causes static errors (in some contexts?) Subject to further refinement and the belief in the WG that the necessary analysis is affordable on smaller systems. To my knowledge this is one of two items on the list requiring interesting compile-time analysis, and though it is desirable it may be too much, given that the run-time semantics are clear enough. We had previously placed all interesting compile-time analyses in the verifier, which was considered optional. > - Function arity checking at run time (ES4 strict only) > - Disable global variable auto-creation when referencing one > from, for example, within a function > - Disallow duplicate formal parameters > - Disallow duplicate names in object initializers > - Disable FunctionObject.arguments (not actually in ES3 but > woefully used in practice) This is an interesting one, since disallowing it would mean that the ES3.1 and ES4 specs would have to re-allow it so that they could explicitly disallow it :) > - (Maybe) Disallow use of arguments object (ES4 strict only) > - (Maybe) Disallow useless expressions Again, compile-time analysis, though lighter weight. Hard to get right and useful at the same time, consider that (x + "") may have effects if x is not a string (its toString is called). > - Prohibit 'with' and locally scoped 'eval'. Globally scoped > 'eval', 'new Function', etc. would still be allowed. Having thought more about this, we may get away with less draconian measures for lexically scoped eval -- it's enough to simply decree that eval may not add bindings to the caller's binding object in strict mode (a simple run-time check, effectively the same as disabling global variable auto-creation). The observation is that reference forms like expr::[expr] require the same functionality as the constrained, lexically scoped eval would require anyway, so the benefit of outlawing eval except for matters of taste is doubtful both in terms of implementation cost and simplified semantics. Thanks for posting the list, I will put together a coherent proposal we can discuss. --lars _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
