Le 01/04/2013 17:22, Tom Van Cutsem a écrit :
Hi David,
The messages you cite discuss the return value of the oddball
"unknownPrivateSymbol" trap.
I assumed the comments applied to true/false protocols in general, but
I'm interested if there is disagreement on that point.
For the preventExtensions trap I see no reason to be inconsistent with
the "set" and "defineProperty" traps.
Historically, the internal operations these relate to needed to return a
boolean and a decision on throwing or not was made based on strictness
of the code. This isn't true for Object.preventExtensions.
Also, Reflect.preventExtensions (and Reflect.set,
Reflect.defineProperty) will make the boolean trap return value
directly visible and usable.
Personally, I find code like:
if (Reflect.preventExtensions(obj)) {
Note that Object.preventExtensions/seal/freeze do not return a boolean,
but the object being manipulated. Is this an expected inconsistency? I
hadn't given a lot of thoughts to it, but that could make a lot of sense.
// success code
} else {
// failure code
}
cleaner than:
try {
Object.preventExtensions(obj);
// success code
} catch (e) {
// failure code
}
Moreover, in the latter piece of code, we may accidentally catch the
wrong exception.
That's what has been necessary to detect whether it was possible to
freeze an host object or not (that is, detecting if it worked).
In any case, since an error can be thrown anyway from the trap (and the
error won't be swallowed), doing a try/catch may still be necessary.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
