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? Tha
I'd be happier with the restriction than without.
2009/2/12 Allen Wirfs-Brock
> 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
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 ri
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
attrib
I'm afraid I haven't had enough time to think all of this through yet.
I feel that there are a few areas where we can separate some concerns
and produce more orthogonal proposals. I'll be sure to post as soon as
I have my thoughts together more.
I understand you would like to move ServerJS
On Sun, Feb 8, 2009 at 4:50 PM, Peter Michaux wrote:
> On Sun, Feb 8, 2009 at 1:06 PM, Dave Herman 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 see is that the proposal leaves
inte
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 :
> 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
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 “eval”
On Thu, Feb 12, 2009 at 5:17 PM, Waldemar Horwat wrote:
> 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.
About five months ago I posted here about improving ECMAScript as a
compilation target.
https://mail.mozilla.org/pipermail/es-discuss/2008-September/007652.html
I was disappointed that there weren't any responses to that email.
Folks were probably busy with other concerns. I also thought there
mi
On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:
About five months ago I posted here about improving ECMAScript as a
compilation target.
https://mail.mozilla.org/pipermail/es-discuss/2008-September/007652.html
I was disappointed that there weren't any responses to that email.
Folks were proba
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 n
On Thu, Feb 12, 2009 at 9:17 PM, Brendan Eich 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 across that
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".
Standardizi
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich 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, for browsers
On Feb 12, 2009, at 10:23 PM, Peter Michaux wrote:
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich
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 committ
17 matches
Mail list logo
