How are people using JSRESOLVE_ASSIGNING now? What, if anything, does SpiderMonkey have to do to ease moving away from it?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How are people using JSRESOLVE_ASSIGNING now? What, if anything, does SpiderMonkey have to do to ease moving away from it?

Jeff Walden-2
The last resolve flag is JSRESOLVE_ASSIGNING.  Once this goes, the JSAPI- user-visible metadata -- the object/value to look up a property on and the name of the property or index of the element -- that has to be specified for a property access will largely be what the spec exposes.  (What those access APIs *do* under the hood will remain more complex than the spec, for now.  But at least the external interface will be pretty similar.)  This is a good thing, and it will enable various cleanups of external interfaces and internal simplifications to the implementation.

I have only preliminarily begun looking at how Gecko uses this flag, and I don't know how complicated it'll be to remove it, just yet.  Many places check for JSRESOLVE_ASSIGNING to avoid lazily defining a property; those can just be removed, at only super-minor performance loss.  (It's a resolve hook -- it's not supposed to be the common case, and a one-time hit is negligible.  Also, using JSRESOLVE_ASSIGNING this way is actually dangerous, because unless you're very careful this will ignore conflicting property attributes.)  Others do more complicated things, and will take more effort.  But I think it'll all be doable, with some work.

That leaves "only" other embedders.  And here there's definitely room for concern.  At least Wes mentioned a bit ago that he depended heavily on this.  Does anyone else?  How are people using this, and for what purposes?  Looking into this is roughly next on my list of things to do, after I finish up a little JSRESOLVE_QUALIFIED work before I can remove that (plus the normal stream of reviews); it seems good to get this feedback ball rolling now, to give people time to explain.

Jeff
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How are people using JSRESOLVE_ASSIGNING now? What, if anything, does SpiderMonkey have to do to ease moving away from it?

Wes Garland
Hi, Jeff!

Thanks for the heads-up. I suspect Mike Moening make depend on this flag,
too.

Wes

On 19 December 2012 21:48, Jeff Walden <[hidden email]> wrote:

> The last resolve flag is JSRESOLVE_ASSIGNING.  Once this goes, the JSAPI-
> user-visible metadata -- the object/value to look up a property on and the
> name of the property or index of the element -- that has to be specified
> for a property access will largely be what the spec exposes.  (What those
> access APIs *do* under the hood will remain more complex than the spec, for
> now.  But at least the external interface will be pretty similar.)  This is
> a good thing, and it will enable various cleanups of external interfaces
> and internal simplifications to the implementation.
>
> I have only preliminarily begun looking at how Gecko uses this flag, and I
> don't know how complicated it'll be to remove it, just yet.  Many places
> check for JSRESOLVE_ASSIGNING to avoid lazily defining a property; those
> can just be removed, at only super-minor performance loss.  (It's a resolve
> hook -- it's not supposed to be the common case, and a one-time hit is
> negligible.  Also, using JSRESOLVE_ASSIGNING this way is actually
> dangerous, because unless you're very careful this will ignore conflicting
> property attributes.)  Others do more complicated things, and will take
> more effort.  But I think it'll all be doable, with some work.
>
> That leaves "only" other embedders.  And here there's definitely room for
> concern.  At least Wes mentioned a bit ago that he depended heavily on
> this.  Does anyone else?  How are people using this, and for what purposes?
>  Looking into this is roughly next on my list of things to do, after I
> finish up a little JSRESOLVE_QUALIFIED work before I can remove that (plus
> the normal stream of reviews); it seems good to get this feedback ball
> rolling now, to give people time to explain.
>
> Jeff
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine