JavaScript:SpiderMonkey:LongTermPlans
The technical plans described below are long-term goals for SpiderMonkey. We aren't necessarily actively working toward completion of any of them. We do try to fix bugs in the short term, in ways that will make these plans easier, or will not get in their way.
If you're interested in any sort of architectural bug-fixing, feel free to work on any of these projects. Some are easier, some are harder and further-reaching, some would have been done already but for their requiring wider-spread changes, without immediate gain. For more details on any of these plans, ask questions in #jsapi.
Object representation
Empowering proxies
Proxies right now are highly entangled with the engine. Working with them often requires diving into friend APIs. As we make no promises about friend APIs remaining anything close to stable, this makes it tricky to use them. We want to gradually change the JSAPI so that if you want an object with any sort of "special" behavior, you implement it as a proxy.
As part of this plan, JSClass will gradually die. The idea of classes is in the middle of deprecation in ECMAScript, so this is a natural step to make. We will still support objects with customized property-lookup, property-getting, property-setting, etc. behavior. These will simply be hooks defined as part of the proxy definition interface, not tied to something named JSClass.
Property/element splitting
...
Introduction of an idiomatic, fully C++ API
Most of the JSAPI is old, C-style JS_* functions. These functions' APIs often aren't particularly simple, clean ways to implement those behaviors. A pleasant C++ API that reads more simply, and doesn't necessarily expose operations through hundreds of freestanding methods, would be nice. We've incrementally introduced such APIs at lower levels -- see for example JS::Value -- but we haven't done anything yet at higher levels. Mostly this is a matter of inertia, and of API design being a bunch of hard work that's off the critical path for Firefox. We'd probably welcome help from embedders and the like with special interest and expertise in designing nice, clean C++ APIs for this stuff. (Do note, however, that we still require an exception-safe API -- true/false return values to indicate success will still probably be necessary.)
Removal of the jsval typedef in favor of JS::Value
jsval and JS::Value are identical. As part of moving more fully to cleaner C++, we should get rid of jsval. Doing so requires cleaning all use of jsval from Gecko -- not hard, but again, just not on anyone's critical path. (Embedders can easily adapt to this by adding typedef JS::Value jsval; to their code as a temporary fix, if needed.)
JSNative's signature will be changed to accept const JS::CallArgs&
The current arguments to JSNative are pretty error-prone. Passing a single class-based argument, that asserts correctness of use, would be preferable -- for correctness checking for sure, and possibly for greater performance (passing one argument being faster than passing two, potentially). We've introduced a helper structure, JS::CallArgs, for this purpose, that can be created from the arguments passed to a JSNative. It's trivial to create such a structure inside every method, then only interact with the arguments through that. New code should use JS::CallArgs exclusively.
Once all of Gecko has switched to JS::CallArgs, we can consider switching JSNative to use it as a parameter -- probably const CallArgs& -- with a minimum of effort. (Unfortunately this effort will involve touching every function implementing the JSNative signature. At least with every function already working in terms of JS::CallArgs, such a patch won't need to touch function logic when it does so.) This is a prerequisite to any such experimentation, or changes to JSNative.