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?
use it with Firebug ourselves. In addition to a huge performance
that may have value. It has very high cost/benefit.
that you want warnings to be fatal, I believe.
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
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.
Wesley W. Garland
Director, Product Development
+1 613 542 2787 x 102
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).
(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.
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
This still seems better than adding JSOPTION_ES5_STRICT.
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.
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
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.