Confirmed users
446
edits
JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions
Jump to navigation
Jump to search
JavaScript:SpiderMonkey:LongTermPlans (view source)
Revision as of 03:04, 4 February 2014
, 4 February 2014Add property descriptor promotion to first-class status, removal of propertyops
(talk about error reporting stuffs) |
(Add property descriptor promotion to first-class status, removal of propertyops) |
||
| Line 10: | Line 10: | ||
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>. | 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>. | ||
=== Replacing the property lookup mechanism with <code><nowiki>[[GetOwnProperty]]</nowiki></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. | |||
=== Property/element splitting === | === Property/element splitting === | ||
| Line 28: | Line 32: | ||
We currently have ''both'' error-reporting, and exception-throwing, error mechanisms. Two is too many. We need to come up with a coherent story for how to deal with all of this, that plays naturally to JS semantics. That probably means that errors should be dealt with only in terms of exception objects. And as far as extracting the information currently in a <code>JSErrorReport</code> goes, that should probably be exposed through a method that takes in a value/object and returns the right data if a usable Error object was passed, or some sort of plausible, partial substitute if not. | We currently have ''both'' error-reporting, and exception-throwing, error mechanisms. Two is too many. We need to come up with a coherent story for how to deal with all of this, that plays naturally to JS semantics. That probably means that errors should be dealt with only in terms of exception objects. And as far as extracting the information currently in a <code>JSErrorReport</code> goes, that should probably be exposed through a method that takes in a value/object and returns the right data if a usable Error object was passed, or some sort of plausible, partial substitute if not. | ||
=== Remove <code>JSPropertyOp</code> and <code>JSStrictPropertyOp</code> === | |||
Having multiple kinds of accessor properties -- the ECMAScript form, and ones with these C++ function-pointer types -- is all sorts of complicated. We should get rid of these types and have all properties be completely understood by, and mappable into, the ECMAScript system. If a property type that's a native C++ function pointer is desired, it should be <code>JSNative</code> -- whose semantics map straightforwardly onto those defined by ECMAScript. | |||
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 == | == JIT == | ||