Hi Jeff,
I agree that the spec should deal with multiple global objects. I'm aware of a
few of the subtleties of multiple globals, but I wouldn't be surprised if there
are more. Thanks for raising this one. I created a placeholder strawman last
week, because I've been intending to get into this topic. I've given it some
contents now, but there's more work to be done. Here's what I've got so far:
http://wiki.ecmascript.org/doku.php?id=strawman:multiple_globals
> The Chrome/Safari behavior would resurrect the vestigial EvalError, so I
> don't think it makes sense. It also contradicts the specification of the
> steps in the definition of the eval function.
I think I agree with this.
> Firefox's behavior is inconsistent and seems not amenable to host-agnostic
> specification as ECMA would require.
I agree that we don't want things like the same-origin policy to show up in the
ES spec. But I'm not sure I'm convinced there isn't a way to specify things
loosely enough that the same-origin policy is consistent with whatever spec we
end up with. I need to chew on that for a while, though.
> Thus we are left with the IE9/Opera behavior, which seems sensible and
> natural to me: an eval function should always act in the context of the
> global from which it came.
Now this I think I don't agree with. The reason is that direct eval is really a
static operator in ECMAScript, not an ordinary function call. It's more than a
function call because, for example, it has access to the lexical environment.
Now, it has this strange dynamic component where, if the value turns out
dynamically *not* to be an evaluation function, then it degenerates into a
function call. But this doesn't change the fact that direct eval is imbued with
special static-operator powers not available to other function calls -- in
particular, access to the lexical environment.
At any rate, I can see two semantics that seem reasonable to me. First let me
make up some terminology: an "apparently direct eval" is a call that's of the
right form to be a direct eval, but whether it actually turns out to be a
direct eval depends on the dynamic value of the callee.
So the two alternatives:
1) an apparently direct eval is a direct eval if its callee is *any* evaluation
function
2) an apparently direct eval is a direct eval *only* if its callee is the
evaluation function of the same global context as the call site
In either alternative, though, the global object of the eval'ed code is the
same global object as the call site. At least for same-origin, semantics #1
agrees with what Firefox is doing. But either one makes sense to me.
As for the same-origin stuff, I'm not yet sure what I think. I'll need to be
schooled in the implications for the browser security model.
> What needs to be done to standardize this behavior? And more generally, what
> needs to be done to begin standardizing multiple globals in ECMAScript,
> including issues like this one?
The above wiki page is a step in that direction, but there's more work to do.
One thing that I think we have to do is nail down the notion of what callee
values constitute an actual direct eval. It's not enough to say "the eval
function," which is as bogus a phrase as "the global object."
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
