Hi John,

(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!)

Anyway... back to your question.

The ECMAScript standard makes these constraints on eval in section  
15.1.2.1, notably
<quote>
I f val ue of t he eval pr opert y i s used i n any way ot her t han a  
di rect cal l ( t hat i s, ot her t han by t he
expl i ci t use of i t s name as an Ident i f i er whi ch i s t he  
MemberExpressi on i n a Cal l Expressi on), or i f t he
eval pr oper t y i s assi gned t o, an Eval Error except i on may be t  
hr own.
</quote>
(Sorry for crappy copy/paste, that's how this is in the ECMA-published  
PDF. Also, I'm sure you were aware of this already, I'm just putting  
it here for the benefit of others reading this thread).

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. 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?

Attila.

[*] I'm also getting the feeling we'd want a mechanism where the Shell  
class can read the required features for a script in a specially  
formatted comment at the beginning of the file...

On Jun 28, 2008, at 6:41 PM, John Resig wrote:

> Hello -
>
> I'd like to be able to do something like the following:
> js> (function(){ eval("var t = 5;"); })();
> js> t
> 5
>
> However it appears as if performing the following always throws an
> exception (even though it is supposed to only throw exceptions under
> strict mode - as far as I can tell):
>
> js> eval.call(this, "var t=5;");
> js: "<stdin>", line 22: uncaught JavaScript runtime exception:
> EvalError: Function "eval" must be called directly, and not by way of
> a function of another name.
>
> As that is the only avenue for evaluating a piece of code within the
> global context - are there any alternatives?
>
> I found this previous thread but it requires adding additional classes
> or methods to external Java files - is there a way to achieve the
> above while remaining in "JavaScript-land"?
> http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/browse_thread/thread/d35cf92bbccc5efe
>
> --John



_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to