A few arrow function specification issues
allen at wirfs-brock.com
Mon Apr 23 17:47:48 PDT 2012
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 , 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. .) 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.
> : http://www.devthought.com/2011/12/22/a-string-is-not-an-error/
> : 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 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss