On Jan 8, 2009, at 9:27 PM, Mark S. Miller wrote:
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.
Oh good -- I misremembered.
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.
It's hard to care, frankly. The Netscape 2 JS1.0 implementation had,
if memory serves, delete as a statement, not an operator. :-P
The rationale "we dare not break" applies to other cases of making the
strict mode migration tax too high. This came up in the wiki just now,
and I've commented in-line at
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_dec_18_2008
Spin-off thread fodder, change of subject appropriate if you take my
bait ;-).
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
