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. -- David-Sarah Hopwood _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
