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 JSClass.getObjectOps
Callback Syntax
typedef JSObjectOps * (* JSGetObjectOps)(JSContext *cx, JSClass *clasp);
| Name | Type | Description |
|---|---|---|
cx |
JSContext * |
The JS context in which the new object is being created. |
cls |
JSClass * |
The class of the new object. |
Description
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 JSObjectMap at 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.
Thus 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 hooks
JSClass offerd following hook:
-
The
JSClass.getObjectOpshook is called each time an object is created. It returns a pointer to aJSObjectOpswhich is then used as a virtual table for operations on the new object.