JS_PreventExtensions 编辑

Attempts to forbid the addition of any new properties to an object.

Syntax

// Added in SpiderMonkey 45

bool
JS_PreventExtensions(JSContext *cx, JS::HandleObject obj, JS::ObjectOpResult &result);

// Obsolete since JSAPI 39

bool
JS_PreventExtensions(JSContext *cx, JS::HandleObject obj, bool *succeeded);
NameTypeDescription
cxJSContext *The context. Requires request. In a JS_THREADSAFE build, the caller must be in a request on this JSContext.
objJS::HandleObjectObject to be made non-extensible.
resultJS::ObjectOpResult &(out parameter) Receives the result of the operation. Added in SpiderMonkey 45
succeededbool *Outparam indicating, on JSAPI success, whether the object is now non-extensible. Obsolete since JSAPI 39

Description

All JavaScript objects recognize the concept of extensibility: whether new properties may be added to the object.  In some situations, it may be convenient to prohibit new properties.  In JavaScript this may be accomplished using the Object.preventExtensions method.  The similar JSAPI method is JS_PreventExtensions.

The failure-mode information below is new as of SpiderMonkey 36.  Before then, JS_PreventExtensions did not accept a succeeded argument; in those cases where *succeeded would be set to false, JS_PreventExtensions would throw a TypeError and return false.

Unlike Object.preventExtensions, JS_PreventExtensions doesn't necessarily throw a TypeError if the object couldn't be made non-extensible.  There are instead two modes of failure: through internal error, and because the object denied the attempt.

The first case occurs when something went wrong internally, not necessarily because the object chose not to become non-extensible.  For example, if making the object requires an allocation, and that allocation fails, out-of-memory might be reported, and JS_PreventExtensions would return false.  This might also occur if the object is a proxy, and some internal state of the proxy means that no coherent behavior is possible.  For example, if the object is a revocable proxy that has been revoked, it makes no sense to say that an attempt to prevent extensions either succeeded or failed: it's a category error.  Thus in this case JS_PreventExtensions will throw an error.

var target = {};
var handler = {};
var pair = Proxy.revocable(target, handler);

var proxy = pair.proxy;
var revoke = pair.revoke;

revoke();

// bool succeeded;
// bool rv = JS_PreventExtensions(cx, proxy, &succeeded);
// // rv == false, succeeded is indeterminate

The second case occurs when no internal error is encountered, but the object simply refuses to be made non-extensible.  For example, a proxy might refuse to be made non-extensible; this refusal would show up in the post-call value of *succeeded.

var target = {};
var handler = { preventExtensions: function(obj) { return false; } };
var obj = new Proxy(target, handler);

// bool succeeded;
// bool rv = JS_PreventExtensions(cx, obj, &succeeded);
// // rv == true, succeeded == false

Note that as with most JSAPI methods, *succeeded is only set if JS_PreventExtensions returns true (that is, does not fail).  Thus you should always check the return value of JS_PreventExtensions, and only if that is true check the value of *succeeded.

See Also

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据

词条统计

浏览:114 次

字数:5944

最后编辑:7年前

编辑次数:0 次

    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文