JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions

== Object representation ==

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, <code>JSClass</code> 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 <code>JSClass</code>.

ECMAScript speaks in terms of properties existing as descriptors, that exist/are owned by a single object.  This is similar to, but not quite the same, as the current <code>lookupProperty</code> mechanism.  We have a bit of work to do to change things so that when someone requests a property, instead of an opaque pointer, they receive (or have filled in) a property descriptor structure.

...

== VM ==

Historically a <code>JSContext</code> included state necessary to run JS code.  These days, most such state is instead stored in <code>JSRuntime</code>, and some state is stored per-compartment or per-global object or per-zone.  If we can move all such information out of <code>JSContext</code>, we should be able to get rid of it entirely.  <code>JSRuntime</code> or global/compartment-centric methods would expose all the same information.

=== Add a warning mechanism distinct from the error-reporting mechanism ===

We've largely gotten rid of property op uses in Gecko, but there's still a bit more work to do before we could make this step and remove the idea completely.  Particularly, there are a few internal uses of property ops in SpiderMonkey that will require careful work to address, before we can remove property ops completely.

== JIT ==

<code>jsval</code> and <code>JS::Value</code> are identical.  As part of moving more fully to cleaner C++, we should get rid of <code>jsval</code>.  Doing so requires cleaning all use of <code>jsval</code> from Gecko -- not hard, but again, just not on anyone's critical path.  (Embedders can easily adapt to this by adding <code>typedef JS::Value jsval;</code> to their code as a temporary fix, if needed.)

=== <code>JSNative</code>'s signature will be changed to accept <code>const JS::CallArgs&</code> ===