Also, removing JSRESOLVE_CLASSNAME

[Jeff Walden]

The JSRESOLVE_CLASSNAME flag (used when looking up properties) is barely used in Gecko or SpiderMonkey at all. Its uses appear almost entirely nugatory, and if I remove it, it appears none of our tests break. Is anyone using this? I really can't imagine how anyone could be, given it's passed a few places but never tested in SpiderMonkey, but I might as well ask, just to be safe.

There is no corresponding thing in any ECMAScript spec to JSRESOLVE_CLASSNAME, so I believe the case is strong for removing this quirk that is directly at odds with the spec algorithms.

Jeff

[Wes Garland]

Fine from my POV (gpsee) -- just don't pull JSRESOLVE_ASSIGNING or
JSRESOLVE_DECLARING! :)

Wes

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Jeff Walden]

On 05/22/2012 03:42 PM, Wes Garland wrote:
> Fine from my POV (gpsee) -- just don't pull JSRESOLVE_ASSIGNING or
> JSRESOLVE_DECLARING! :)

In the long run I'd like to remove all resolve flags -- there's no such concept in the spec, and they create headaches every time anyone has to think about them. But that's a ways out, definitely.

Removing JSRESOLVE_ASSIGNING is probably impractical right now (there are 50-odd hits in Gecko for it), so I don't think you need to worry about that right now.

But JSRESOLVE_DECLARING looks potentially removable, from the Gecko end. (I'm tryservering a patch now to get better data.) Now that variable declarations, function statements, and consts all *define* the property they declare, rather than simply set it (I believe this changed with bug 632003 and bug 577325), I don't think this flag serves any purpose in SpiderMonkey or Gecko any more. How are you using it?

Jeff

[Wes Garland]

Code: http://code.google.com/p/gpsee/source/browse/gpsee_modules.c#193

Our architecture is such that we have CommonJS 1.x modules, with each
module having it's own global object, as a sort of "module scope".

We then use a resolver on these module scope objects to allow module code
to resolve references to the real global object -- the one that the program
module runs, and owns Math, Array, etc.

JSRESOLVE_DECLARING helps us to decide *not* to proxy through the to "true"
global when the programmer uses 'var' to declare a variable which is scoped
to the module.

This strange set of circumstances arose because the JIT was penalizing us
for using a scope object which was not a global object in
JS_ExecuteScript(). Other scenarios have been considered to achieve the
same goal, but they all require re-writing the JS before executing it.

Wes