The rationale for strict mode
David-Sarah Hopwood wrote:
Section 4 of the Kona draft says:
[...] A scripting language is intended for use by both professional
and nonprofessional programmers. To accommodate non-professional
programmers, some aspects of the language are defined to be tolerant
of programmer mistakes. However, such tolerance can easily result in
programs containing undiscovered errors that professional programmers
would wish to discover and correct. To facilitate such error detection
script can be explicitly declared to use a "strict" variant of the
full ECMAScript language that provides enhanced error detection as well.
[...]
Suggested change:
- delete the above two sentences.
Four sentences, I meant.
On Thu, Nov 13, 2008 at 2:53 PM, David-Sarah Hopwood < david.hopwood at industrial-designers.co.uk> wrote:
[...] Strict mode reports many error conditions, such as accessing a non-existent property of an object, by throwing an exception. In non-strict mode these conditions silently cause the operation to be ignored or the 'undefined' value to be used as the result. [...]mail.mozilla.org/listinfo/es3.x-discuss
Hi David-Sarah, I like everything about your message, except that the above example specifically is incorrect. Because the JavaScript "feature testing" pattern is so ingrained, and because the failure does manifest in an undefined value which is likely to be noticed, strict mode does not change the behavior of a failed read. For the same reasons, neither does Caja.
If you change your example to a failed assignment, everything works.
On Nov 13, 2008, at 2:53 PM, David-Sarah Hopwood wrote:
Section 4 of the Kona draft says:
[...] A scripting language is intended for use by both professional
and nonprofessional programmers. To accommodate non-professional
programmers, some aspects of the language are defined to be tolerant
of programmer mistakes. However, such tolerance can easily result in
programs containing undiscovered errors that professional
programmers
would wish to discover and correct. To facilitate such error
detection
script can be explicitly declared to use a "strict" variant of the
full ECMAScript language that provides enhanced error detection as
well.
I agree this should all be removed. It's neither accurate history nor
sound rationale.
Section 4 of the Kona draft says:
[...] A scripting language is intended for use by both professional
and nonprofessional programmers. To accommodate non-professional
programmers, some aspects of the language are defined to be tolerant
of programmer mistakes. However, such tolerance can easily result in
programs containing undiscovered errors that professional programmers
would wish to discover and correct. To facilitate such error detection
script can be explicitly declared to use a "strict" variant of the
full ECMAScript language that provides enhanced error detection as well.
However, being "tolerant of programmer mistakes" is a very different thing than failing silently on errors that are commonly caused by programmer mistakes, which is what ES3, and ES3.1 in non-strict mode, actually do.
One could make a convincing argument that the behaviour that is most tolerant of mistakes is to report error conditions resulting from the mistake as soon as possible, in as many cases as possible. For that reason, I would strongly advise anyone teaching JavaScript to teach the ES3.1-strict subset, especially to beginning programmers.
The basic technical rationale for strict mode is that there were some language design flaws that we couldn't compatibly fix without using an opt-in. Strict mode is that opt-in. It has nothing much to do with whether programmers are professional, or amateur, or unprofessional.
I understand why, for political reasons, the standard document can't actually say that the lax semantics and silent failures of JavaScript were just bad language design. However, if it can't say that then it should at least avoid trying to rationalize historical mistakes. The text quoted above does not provide a helpful or accurate rationale for either mode.
Suggested change:
delete the above two sentences.
add the following, perhaps before the "A scripting language ..." paragraph:
ECMAScript code can be run in two modes, "strict" and "non-strict" (these may be mixed in the same program). Strict mode reports many error conditions, such as accessing a non-existent property of an object, by throwing an exception. In non-strict mode these conditions silently cause the operation to be ignored or the 'undefined' value to be used as the result. Previous versions of ECMAScript supported only the non-strict semantics. Although the strict semantics are generally preferable, the behavior could not be compatibly changed without adding strict mode as an "opt-in" mode.