destructuring: as patterns?

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Apr 23 10:00:49 PDT 2012


On Apr 23, 2012, at 2:40 AM, Andreas Rossberg wrote:

> On 21 April 2012 11:56, Herby Vojčík <herby at mailbox.sk> wrote:
> 
...
> 
>> JS model _is_ about "sloppy semantics" (I do not call it sloopy, I'd rather
>> called it liberal), that is, undefined if not present.
> 
> It's a term sometimes used on TC39, I didn't invent it (I used to call
> it "classic" mode for improved neutrality).
> 
> I may take issues with associating pre-strict-mode sweeping under the
> rug with liberal ideals, though. :)

I like Martin Rinard's concept of code that is  "failure oblivious" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.9926&rep=rep1&type=pdf 

Arguably, the robustness of the web is dependent up the fact many Javascript based webpages will continue to operate, perhaps in a slight degraded mode, even in the face of runtime errors.  I'm all for "early errors" that cause a structurally ill-formed script from loading.  But for a well-formed program I don't see why throwing a (probably uncaught) exception is necessarily any more robust than simply returning undefined when various dynamic failures (such as the destructuring situations we are talking about) are encountered.

To me, undefined propagation  feels a lot like NaN propagation in numeric expressions.  Those of us who don't do a lot of numeric computation may be puzzled by NaNs, but it is a lot easier to simply let a NaN propagate through a complex formula and check it at the end, then it is to check for an exception on each operation of the formula.  And, sometimes it turns out that the NaN didn't really matter at all...

It is important that JavaScript programmer are able to harden the failure critical portions of their applications.  Trying to automatically harden everything may actually make JS a less useful languages.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120423/2cdf069c/attachment-0001.html>


More information about the es-discuss mailing list