On Jul 2, 1:53 pm, [EMAIL PROTECTED] wrote:
> On Jul 2, 10:05 am, Attila Szegedi <[EMAIL PROTECTED]> wrote:
>
>
>
> > > 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?
>
> > Don't want to speak in John's name, but I think it would. eval.call
> > and eval.apply would help him achieve what he wanted, and we could
> > still keep the optimization. It's aliasing the eval that'd make the
> > optimization impossible...
>
> > Attila.
>
> We have a bug report (in the HtmlUnit project) where someone is
> complaining about not being able to alias eval (because all of the
> native browsers allow this). So for us, this partial fix wouldn't
> work. Any chance we can allow eval aliasing in interpreted mode
> (possibly subject to some FEATURE_XXX config)?
I tried this on a recent SpiderMonkey build:
js> eval.call(this, "var x = 3;")
js> x
3
js> var obj = {}
js> eval.call(obj, "var x = 7")
typein:6: EvalError: function eval must be called directly, and not by
way of a
function of another name
js> function f() {
eval.call(this, "var x = 8")
}
js> f()
js> x
8
So eval.call appears only to work on the global scope. Seems like an
odd distinction. This would work for John's case, but not for the more
general HtmlUnit case (although I get similar behavior in Firefox 3 as
you'd expect, so perhaps it's not an issue for HtmlUnit).
--N
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
