638
edits
JavaScript:ActionMonkey: Difference between revisions
→Stage 4: still more work for Jim
(→Stage 4: add more work for jim) |
(→Stage 4: still more work for Jim) |
||
| Line 98: | Line 98: | ||
* Change the interpreter to use Tamarin strings. | * Change the interpreter to use Tamarin strings. | ||
* Change the interpreter to use Tamarin jsvals. | * Change the interpreter to use Tamarin jsvals. | ||
* Implement an adapter class to support Tamarin objects that preserve the <code>JSObjectOps</code> and <code> | * Figure out what to do when an application calls <code>[[JS_GetClass]]</code> on a plain <code>Object</code>, <code>Array</code>, or <code>Function</code>. | ||
* Figure out how to support the "last-retrieved value" behavior of <code>[[JS_LookupProperty]]</code>. | |||
* Figure out how to support native getters, setters, and <code>[[JSClass]]</code> hooks. | |||
* Figure out how to support <code>[[JSObjectOps]]</code> callbacks. ''Or'' find the people to reimplement all Mozilla's <code>JSObjectOps</code>-level magic on Tamarin's object model. | |||
* Implement an adapter class to support Tamarin objects that preserve the <code>JSClass</code> behavior (and <code>JSObjectOps</code> if necessary). | |||
* Implement support for using <code>JSNative</code> and <code>JSFastNative</code> native functions in the Tamarin object model. | |||
* Change the interpreter to use Tamarin objects. | * Change the interpreter to use Tamarin objects. | ||
* Make sure jsxdrapi.h works with the new object model. | * Make sure jsxdrapi.h works with the new object model. | ||
* Make sure E4X works with the new object model. | * Make sure E4X works with the new object model. | ||
* Make sure the debugger still works with the new object model. | * Make sure the debugger still works with the new object model. | ||
* Merge the SpiderMonkey and Tamarin <code>Array</code> implementations. | |||
It's undecided how all this might land in mozilla-central. I don't think performance regressions can be avoided given the nature of what we're doing here. It seems more sensible to move ahead to Stage 5, in a branch if necessary, than to | It's undecided how all this might land in mozilla-central. I don't think performance regressions can be avoided given the nature of what we're doing here. It seems more sensible to move ahead to Stage 5, in a branch if necessary, than to do ''that much'' tuning of this Frankenstein's monster. | ||
== Stage 5 == | == Stage 5 == | ||