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 <[email protected]>
> 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
> [email protected]
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
