Now that we have decided that all declarations of the identifier eval are
banned from strict code a related question has come up from one of the
implementers of our strict mode prototype implementation.Why does Es3.1
still allow assignment to the identifier eval within strict code? That
I'd be happier with the restriction than without.
2009/2/12 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com
Now that we have decided that all declarations of the identifier eval
are banned from strict code a related question has come up from one of the
implementers of our strict mode
I wouldn't worry about feature creep in terms of strict mode
forbidding certain identifiers in unambiguous grammatical positions.
Some implementations already have to work harder if arguments is the
left-hand side of assignment within a function. Such parser tweaks are
also easier to get
ES3 10.1.3 says:
For each FunctionDeclaration in the code, in source text order,
create a property of the variable object whose name is the Identifier
in the FunctionDeclaration, whose value is the result returned by
creating a Function object as described in section 13, and whose
On Sun, Feb 8, 2009 at 4:50 PM, Peter Michaux petermich...@gmail.com wrote:
On Sun, Feb 8, 2009 at 1:06 PM, Dave Herman dher...@ccs.neu.edu wrote:
I like many aspects of Ihab and Kris's proposal, but not all.
For example which parts do you like or dislike?
Speaking for myself, one problem I
If we no longer throw EvalError, we should take the class out of the body of
the spec too. It just clutters things up.
The obvious place for such obsolete things is Annex B. It contains such gems
as Date.getYear and octal digits in literals.
Waldemar
2009/2/12 Brendan Eich bren...@mozilla.com:
I wouldn't worry about feature creep in terms of strict mode forbidding
certain identifiers in unambiguous grammatical positions. Some
implementations already have to work harder if arguments is the left-hand
side of assignment within a function.
Allen Wirfs-Brock wrote:
Now that we have decided that all declarations of the identifier “eval”
are banned from strict code a related question has come up from one of
the implementers of our strict mode prototype implementation.Why
does Es3.1 still allow assignment to the identifier
On Thu, Feb 12, 2009 at 5:17 PM, Waldemar Horwat walde...@google.comwrote:
Allen Wirfs-Brock wrote:
Now that we have decided that all declarations of the identifier eval
are banned from strict code a related question has come up from one of the
implementers of our strict mode prototype
On Feb 12, 2009, at 9:17 PM, Brendan Eich wrote:
The JVM bytecode is a counter-example and we are not going to
standardize anything like it in the near term (next few years).
I meant by counter-example an example of what not to do. Same goes
for SWF ABC (used by Flash), which Adobe does
On Thu, Feb 12, 2009 at 9:17 PM, Brendan Eich bren...@mozilla.com wrote:
On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:
SpiderMonkey has had __noSuchMethod__ for years. The Ten years complaint
you make seems to be against the ECMAScript committee,
Not at all and it is unfortunate it came
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
Not at all and it is unfortunate it came across that way. It is at the
whole chain of events which is long: for the ECMAScript committee to
standardize methodMissing, for browsers to implement it and for old
browsers to disappear.
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich bren...@mozilla.com wrote:
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
Not at all and it is unfortunate it came across that way. It is at the
whole chain of events which is long: for the ECMAScript committee to
standardize methodMissing,
On Feb 12, 2009, at 10:23 PM, Peter Michaux wrote:
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich bren...@mozilla.com
wrote:
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
Not at all and it is unfortunate it came across that way. It is at
the
whole chain of events which is long: for the
14 matches
Mail list logo
