A few arrow function specification issues

Mark S. Miller erights at google.com
Mon Apr 23 18:09:27 PDT 2012

On Mon, Apr 23, 2012 at 5:47 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> On Apr 23, 2012, at 4:59 PM, Domenic Denicola wrote:
> As a day-to-day user who was not using strict until recently (stubborn
> other team member for the loss), I can say that moving to strict was much
> more a "cleanup" experience than a "mode" experience, with only a few small
> exceptions:
> 1) Poison-pilling arguments.callee: some code on the internet (notably
> [1], but elsewhere too) uses this property.
> 2) Throw on `delete`ing non-configurables: unlike the other
> throw-on-doing-something-bad, `delete`ing non-configurable properties was
> something we actually did on purpose. E.g. using it to clear an "entry" in
> a "map", whether or not that entry was ever filled. (Cf. [2].) We never
> tried writing to a non-writable property, because that would cause bugs,
> but `delete`ing a property that doesn't exist was a common pattern.
> [1]: http://www.devthought.com/2011/12/22/a-string-is-not-an-error/
> [2]:
> https://github.com/cjohansen/Sinon.JS/commit/80c38bd3e4b8813ab74ef27a4db3646e4778e31c
> The delete issue is very much along the lines of what I was referring to
> in another thread[3] today regarding "failure oblivious computing".  I just
> don't think I see a big benefit from a throw  in the situation of deleting
> a non-configurable property, particularly since there was already another
> mechanism (delete operator returns false) that indicates that the delete
> could not be performed.
> IMO, this the delete strict mode throw was unnecessary and borders on
> being a bad idea. Perhaps we could remove it from ES6.  How much strict
> mode code do we think is going to actually be dependent on getting that
> exception?


The "failure oblivious computing" stuff is fascinating, but I wouldn't try
it at home. Such code proceeds silently after it has lost integrity. Not
great for anything important. Completely useless for code that must
maintain integrity under adversarial conditions.

> [3]: https://mail.mozilla.org/pipermail/es-discuss/2012-April/022526.html
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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

More information about the es-discuss mailing list