On Jul 1, 2:03 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> Attila -
>
> > (just got a copy of your Pro JavaScript Techniques today from Amazon -- I'll
> > be making its first 75 pages (we're into server side JS) a required reading
> > for all devs in my organization!)
>
> Awesome! I just finished the first 1/3 of my new JavaScript book
> (Secrets of the JavaScript Ninja) covering the advanced concepts of
> JavaScript - it should be a good successor to my other book.
>
> > It does say an EvalError "may" be thrown", not "must be thrown" so indeed we
> > might allow a relaxation on it when in non-strict mode.
>
> As far as I can tell Rhino is the only engine that makes it "must"
> instead of "may" - which is quite confusing and frustrating.
>
>
>
> > Now, Rhino actually
> > does have three "FEATURE_STRICT_*" constants already: FEATURE_STRICT_VARS,
> > FEATURE_STRICT_EVAL, and FEATURE_STRICT_MODE. FEATURE_STRICT_EVAL seems like
> > it's what you're looking for, but actually it has different semantics, its
> > docs say:
>
> > * When the feature is on Rhino reports runtime errors if non-string
> > * argument is passed to the eval function. When the feature is off
> > * eval simply return non-string argument as is without performing any
> > * evaluation as required by ECMA 262.
>
> > I'm wondering if it would make sense to expand its semantics to also lift
> > 15.1.2.1 restrictions on Global.eval, or maybe we introduce yet another
> > feature constant (apparently, you can never have enough of them :-) ) [*]
>
> > What do others think?
>
> Anything that can be done would be appreciated - I'm kind of stuck
> right now, since globally evaluating the code doesn't seem to be an
> option. Hmm...
>
> --John
I should explain why limitation on calling eval by another name is in
the spec. It turns out it is due to Rhino...
One of the biggest sources of efficiency in compiling JS to bytecode
on the JVM is to avoid creating an activation object. (An activation
object is an object representing the function level-scope; all
variables of the function are represented as properties of the
activation object.) Certain language features in JavaScript can't be
implemented without an activation object, and eval is one of them.
Consider the following:
js> function f() {
> eval("var x = 5;");
> return x;
> }
js> f()
5
In function f(), the variable x is only defined as a side effect of
the call to eval. We can't determine at compile time what variables
are present in a function, so we can't allocate JVM registers to them.
When compiling a function, Rhino looks for the constructs like eval
that require an activation object. If it doesn't see them, it won't
create an activation object. Great! Now we have the eval feature and
we have fast code when we don't use it. But consider the following:
js> function f() {
> g("var x = 5;");
> return x;
> }
js> var g = eval
When compiling f(), Rhino *has no way to know that g could be eval*.
So if we supported calling eval by a function of another name, Rhino
would never be able to avoid creating the activation object for any
function that calls another function. So Rhino handles calls to "eval"
differently than calls to other function names. We were building Rhino
at the time the ECMA spec was being finalized, and asked that this
special wording be put into the spec specifically so implementations
like Rhino could compile more efficiently.
So what do we do in this case? It seems like we could extend Rhino to
handle eval.call specially, much like eval is handled specially. That
seems like a reasonable approach; would it solve your problem?
--N
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
