Implementing ES5 strict mode
Jim Blandy
ES5 strict mode":
There was some discussion about implementing this by morphing the code
currently present to support JSOPTION_STRICT /* warn on dubious practice
*/ and JSOPTION_WERROR /* convert warning to error */ into something
that yields the appropriate ES5 behavior. A "using strict" directive in
global code or a function would have the same effects as setting
JSOPTION_STRICT|JSOPTION_WERROR for that code. This would leverage
existing work, and avoid having two things called "strict" (one for C
API compatibility, and one mandated by the language spec).
Am I understanding what I've read correctly? Any big surprises folks
can warn me about, details I should look out for?
Jeff Walden
> There was some discussion about implementing this by morphing the code
> currently present to support JSOPTION_STRICT /* warn on dubious practice
> */ and JSOPTION_WERROR /* convert warning to error */ into something
> that yields the appropriate ES5 behavior. A "using strict" directive in
> global code or a function would have the same effects as setting
> JSOPTION_STRICT|JSOPTION_WERROR for that code. This would leverage
> existing work, and avoid having two things called "strict" (one for C
> API compatibility, and one mandated by the language spec).
>
> Am I understanding what I've read correctly? Any big surprises folks can
> warn me about, details I should look out for?
I think this requires changes to what the javascript.options.strict preference means, or replacing it with a newly-named preference. There's a long tradition of suggesting extension developers set this preference, and if it were to suddenly start actually breaking functionality for those developers, That Would Be Bad. (I have it set in mine, and judging by the spew I see in the console, tons of webpages produce these warnings and would break if you implemented exactly as you suggest here.)
Jeff
John J. Barton
I advise Firebug users to avoid javascript.options.strict and we don't
use it with Firebug ourselves. In addition to a huge performance
penalty, it warns on normal Javascript practice, obscuring any warning
that may have value. It has very high cost/benefit.
jjb
Mike Shaver
Only if you also set the pref (javascript.options.werror?) to indicate
that you want warnings to be fatal, I believe.
Mike
Wes Garland
> I advise Firebug users to avoid javascript.options.strict and we don't use
> it with Firebug ourselves. In addition to a huge performance penalty, it
> warns on normal Javascript practice, obscuring any warning that may have
> value. It has very high cost/benefit.
I advise my local developers (using JS on the server side) to always use
strict mode; in fact, they have to throw extra CLI flags to turn it off.
This works well when the code is developed "warning-free" from day one. I
must admit, I have never noticed a performance issue related to
JSOPTION_STRICT, even on slow CPU, although I have not measured.
We do not normally run JSOPTION_WERROR, I generally find that it contributes
little (except under test harness) and is an impediment to aglie
development.
I would welcome the addition of ES5 strict mode any way it's available, as
part of JSOPTION_STRICT or otherwise. Although, two separate strict modes
would be awfully confusing.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Boris Zbarsky
> I advise my local developers (using JS on the server side) to always use
> strict mode; in fact, they have to throw extra CLI flags to turn it off.
> This works well when the code is developed "warning-free" from day one. I
> must admit, I have never noticed a performance issue related to
> JSOPTION_STRICT, even on slow CPU, although I have not measured.
The performance issue comes in if you write code that triggers thousands
of strict warnings; the cost of reporting all those warnings is what
causes a performance penalty. Especially if your reporting mechanism is
heavyweight (e.g. in John's case the Firefox error console).
-Boris
John J. Barton
(Actually I have four consoles ;-).
The other place this hits is almost every web site: if you are
developing extensions to Firefox it will bite you.
But if you have total control of the source, maybe it's not a penalty.
jjb
Brendan Eich
Right, there's no incompatible change to JSOPTION_STRICT's meaning
warning not error. There will be marginal (IMHO) changes for worse and
better in what strictness warnings you get.
The "use strict"; pragma (not "using strict", note well) enables
JSOPTION_WERROR too. But the options are still independent in the JS
API.
This still seems better than adding JSOPTION_ES5_STRICT.
/be
Jim Blandy
Yeah. I think all we're talking about here is 1) shifting the
conditions about which JSOPTION_STRICT complains, and 2) providing an
in-language way to turn it on, along with JSOPTION_WERROR, for localized
areas of code.
The conditions JSOPTION_STRICT detects aren't a particularly constrained
category to begin with --- just "dubious practice". We want to align
our notion of "dubious" with ES5's.
Jim Blandy
You know, ES5 strict mode can be established for a single function (and
any nested functions), or a particular piece of global code. I wonder
if the same or similar mechanisms could also be used to support a
chrome-only strict option, javascript.options.strict.chrome or whatever.
John J Barton
...
> You know, ES5 strict mode can be established for a single function (and
> any nested functions), or a particular piece of global code. I wonder
> if the same or similar mechanisms could also be used to support a
> chrome-only strict option, javascript.options.strict.chrome or whatever.
If the language based strict mode is available, then the mozilla JS code
can set it and the global strict option can be turned off. We don't need
a chrome only strict option.
jjb