Obsolete since JSAPI 17
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
JSGetObjectOps is the type for
typedef JSObjectOps * (* JSGetObjectOps)(JSContext *cx, JSClass *clasp);
||The JS context in which the new object is being created.|
||The class of the new object.|
JSObjectOps is used by
JS_NewObject's internals to discover the set of high-level object operations to use for new objects of the given class. All native objects have a
JSClass, which is stored as a private (int-tagged) pointer in object slots. In contrast, all native and host objects have a
obj->map, which may be shared among a number of objects, and which contains the
JSObjectOps *ops pointer used to dispatch object operations from API calls.
JSClass (which pre-dates
JSObjectOps in the API) provides a low-level interface to class-specific code and data, while
JSObjectOps allows for a higher level of operation, which does not use the object's class except to find the class's
JSObjectOps struct, by calling
clasp->getObjectOps, and to finalize the object.
If this seems backwards, that's because it is! API compatibility requires a
JSClass *clasp parameter to
JS_NewObject, etc. Most host objects do not need to implement the larger
JSObjectOps, and can share the common
JSScope code and data used by the native (
js_ObjectOps, see jsobj.c) ops.
Further extension to preserve API compatibility: if this function returns a pointer to
JSXMLObjectOps.base, not to
JSObjectOps, then the engine calls extended hooks needed for E4X.
JSClass offerd following hook: