JSObject Makeover

Possible JSObject changes

• ops belongs on obj, not map
• shape belongs on obj, not map, for cache-ready object types
• obj should be something we can easily subclass, as we do with JSFunction

Possible JSObjectOps changes

• New ops "getPropertyForCache", etc. that populate the property cache. The

interpreter/recorder would only call these on a cache miss.

• 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.

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.

Possible JSAPI changes

• Stop exposing JSObjectOps via jsapi.h.

• Start phasing out JSClass from the API too. Deprecate JSExtendedClass. (Once we have ops for everything, I think we can mostly stop using JSClass internally too. Depends on a few things.)

• Add a stable API (to replace JS_InitClass) for creating a constructor

from a static class-description. This would create a new JSObjectOps behind the scenes. Individual class-description features could come and go without requiring API changes that would affect code not using those features.

• Add an API for creating objects from constructors, as though with new

constructor(args).

• Add a stable API for wrapping objects (and maybe for hacking objects via

stackable JSObjectOps).

• Kill resolve flags, of course. Deprecate JS_LookupPropertyWithFlags.