Is EvalError still needed?
Are there implementations that throw it? I thought there was at least one.
WaldemarI've been told that Opera does (or at least did). However, Opera 9.63 on windows doesn't appear to. Maybe it's the mobile version that does it.
Regardless, the clarification of the semantic difference between direct and indirect eval arguably makes the optional disallowance of indirect eval obsolete. Indirect eval would seem to have no utility (at least for web applications) if it is an "optional" feature.
Chris Pine answered this one recently:
Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote leave it in the spec. with a note that says it isn't currently used and exists for compatibility with previous ES editions.]
On Tue, Feb 10, 2009 at 6:42 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote leave it in the spec. with a note that says it isn't currently used and exists for compatibility with previous ES editions.]
I agree on both
On Feb 10, 2009, at 7:23 PM, Mark S. Miller wrote:
On Tue, Feb 10, 2009 at 6:42 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com
wrote: Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote
leave it in the spec. with a note that says it isn't currently used
and exists for compatibility with previous ES editions.]I agree on both
+1
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.
WaldemarI ending up using EvalError for the strict mode situations where we forbid declaration of "eval".
On Feb 13, 2009, at 9:46 AM, Allen Wirfs-Brock wrote:
I ending up using EvalError for the strict mode situations where we
forbid declaration of "eval".
+1, FWIW.
The Mountain View notes don't directly address this and I don't recall us discussing it specifically at the meeting but it seems that the formalization of direct and indirect evals and their scoping means that the ES3 permission for an implementation to essentially forbid indirect evals or the changing of the global value of eval is no longer necessary or desirable:
"If the value of the eval property is used in any way other than a direct call (that is, other than by the explicit use of its name as an Identifier which is the MemberExpression in a CallExpression), or if the eval property is assigned to, an EvalError exception may be thrown."
Any disagreement? Can we delete the above paragraph? (I've already taken care that direct eval is adequately defined elsewhere).
If we do delete this paragraph , then there are no longer any places in the specification that specify the throwing of an EvalError (I've already gotten rid of the only other occurrences which were in 10.6 (Declaration Binding Instantiation) and related to strict mode evals). If we don't specify any use of EvalError what should we do with it? Remove it from the ES3.1 spec? (probably not) Keep it for legacy compatibility? (probably) Say it is reserved for implementation usage? Any other ideas?