<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 8, 2009, at 9:27 PM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [lots of agreement]</blockquote><div><br>Wonderful!<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br> <font color="#888888"> </font></blockquote><div>&nbsp;</div></div>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. </blockquote><div><br></div>Oh good -- I misremembered.</div><div><br></div><div><br><blockquote type="cite">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.</blockquote><div><br></div>It's hard to care, frankly. The Netscape 2 JS1.0 implementation had, if memory serves, delete as a statement, not an operator. :-P</div><div><br></div><div>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</div><div><br></div><div><a href="http://wiki.ecmascript.org/doku.php?id=meetings:minutes_dec_18_2008">http://wiki.ecmascript.org/doku.php?id=meetings:minutes_dec_18_2008</a></div><div><br></div><div>Spin-off thread fodder, change of subject appropriate if you take my bait ;-).</div><div><br></div><div>/be</div><div><br></div></body></html>