On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich <[email protected]> wrote:
> [lots of agreement] Wonderful! > Generic programming with primtiives more often wants to *read* undefined > when getting a non-existent property, and "object detect" without having to > try/catch. This common use case is not served by strict mode in ES3.1, > right? You'd have to change code to try/catch around such probes. > ES3.1-strict and nonstrict both return undefined from a failed read for exactly this reason, as does Caja. The feature testing pattern is pervasive and we dared not break it. The rationale is that a failed read is *not* silent n practice, and so is adequately non-hazardous for integrity. It returns an undefined, which is likely to be noticed, since the operation in question is, after all, a read. This rationale does not apply to "delete" returning false, since in practice much code calls delete, assumes success, and does not check the return value. In the face of new user-defined non-configurable properties, failed deletes will be more common, so this hazard becomes worse. So a failed strict delete does throw. You do indeed have to place try/catches around strict deletes to simulate their current behavior. -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
