15
edits
JSObject Makeover: Difference between revisions
m
→Possible JSObjectOps changes
| Line 36: | Line 36: | ||
* New ops for stuff like "hasInstance", "hasProperty", "hasOwnProperty", so that (a) lookupProperty isn't quite so overloaded and thus doesn't have to use cx->resolveFlags and bytecode inspection; (b) we can do everything we need to do to an object via ops, so objects are wrappable and ops are easily stackable. | * New ops for stuff like "hasInstance", "hasProperty", "hasOwnProperty", so that (a) lookupProperty isn't quite so overloaded and thus doesn't have to use cx->resolveFlags and bytecode inspection; (b) we can do everything we need to do to an object via ops, so objects are wrappable and ops are easily stackable. | ||
* Another alternative is to replace JSObjectOps with a tag describing nature of the object and then call specialized methods based on the tag and types of arguments. This would closely reflect what the current code is doing with explicit _IS_NATIVE or _IS_XML checks. It would also | * Another alternative is to replace JSObjectOps with a tag describing nature of the object and then call specialized methods based on the tag and types of arguments. This would closely reflect what the current code is doing with explicit _IS_NATIVE or _IS_XML checks. It would also match the tracer with its generation of explicit guards on object's type. | ||
Note that the current machinery avoids recursing on the C stack by iterating instead when the prototype _IS_NATIVE. If we plan to wrap and stack freely, we'll want to avoid recursion in a less hackish way, e.g. by designing the ops to do tail calls or by making some ops refer only to "own" properties. | Note that the current machinery avoids recursing on the C stack by iterating instead when the prototype _IS_NATIVE. If we plan to wrap and stack freely, we'll want to avoid recursion in a less hackish way, e.g. by designing the ops to do tail calls or by making some ops refer only to "own" properties. | ||