On Jul 4, 2:17 pm, Norris Boyd <[EMAIL PROTECTED]> wrote:
> 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
I submitted a change to allow indirect calls to eval as long as the
execution scope is the global scope. A build is available at
ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_7R2pre.zip.
--N
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
