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 _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
