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.getObjectOps
hook is called each time an object is created. It returns a pointer to aJSObjectOps
which is then used as a virtual table for operations on the new object.