preventExtensions trap and its true/false protocol

Tom Van Cutsem tomvc.be at gmail.com
Mon Apr 1 08:22:27 PDT 2013


Hi David,

The messages you cite discuss the return value of the oddball
"unknownPrivateSymbol" trap.

For the preventExtensions trap I see no reason to be inconsistent with the
"set" and "defineProperty" traps.

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)) {
  // 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.

In short, I don't see what's wrong with the boolean return value protocol.
I find it much cleaner than the throw/return protocol. In addition, boolean
return values can be more easily combined using the boolean operators.
throw/return exit "signals" can't be combined that straightforwardly.

Cheers,
Tom


2013/4/1 David Bruant <bruant.d at gmail.com>

> Le 31/03/2013 21:17, Jeff Walden a écrit :
>
>  On 03/31/2013 11:02 AM, David Bruant wrote:
>>
>>>  From the developer perspective, this doesn't really add anything since
>>> it's already possible to throw from within the trap (and that's probably
>>> more explicit and clearer than returning false).
>>>
>> That puts the onus on the trap to throw the correct kind of error, right?
>>
> What do you mean by "correct"? It's already possible to throw any sort of
> error from any trap; I'm not sure what's correct and what isn't in that
> context.
>
>
>  Admittedly this should be easy enough to get right, but it is a slight
>> bit of extra complexity, versus having the implementation throw the correct
>> error in one central location.
>>
> I think the difference is at best marginal.
> As a reader of people writing JS code, I'd rather have people explicitly
> throwing than having to remember which trap has a true/false protocol.
> As a web developer, I'm happy if the surface of things to test for web
> browser implementors is smaller ;-) (and that's going to be a net reduction
> in terms of spec and I guess in implementations if the trap result is just
> ignored)
>
> David
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130401/33ac89d7/attachment.html>


More information about the es-discuss mailing list