Mark S. Miller (2015-02-19T17:41:43.000Z)
d at domenic.me (2015-02-22T03:29:09.249Z)
On Thu, Feb 19, 2015 at 9:23 AM, David Bruant <bruant.d at gmail.com> wrote: > It's obviously possible to replace all built-in props by accessors [4], of > course, but this is a bit ridiculous. It is indeed ridiculous. Not fixing this in the ES5 timeframe was my single biggest failure and disappointment as a member of TC39. For reference, Caja's implementation of the technique described in [4] is at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#278 As it states, our term for freezing an object so that it does not provoke this problem is "tamper proofing". > Can the override mistake be fixed? I imagine no web compat issues would > occur since this change is about throwing less errors. There was a time when some of the browsers did not suffer from the override mistake, and in so doing, were technically out of conformance with the ES5 spec. During this window, it was clearly still web compatible to fix the override mistake. It was during this window that I raised the issue and argued that it be fixed. I brought this up in meetings several times and never made any progress. Once all browsers suffered equally from the override mistake, it was no longer *clearly* web compatible to fix it, so I gave up and focused on other things instead. However, I agree with your suspicion that it actually would still be web compatible to fix this. Unfortunately, the only way to find out at this point is for a browser to try deploying without the override mistake. I don't have much hope. Instead, I suggest you promote tamper proofing to those audiences to which you currently promote freezing. Though the need for it is indeed ridiculous, it actually works rather well. We've been using it successfully for many years now.