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?
>

-1.

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
>
>


-- 
    Cheers,
    --MarkM
-------------- 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