On 9 January 2012 21:41, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: > > On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: > ... > > The other change I hope fits into the same bucket is > <http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake>. > Right now, because of pressure from test262, we are in danger of having all > browsers conform to this mistake, at which point it may be too late to fix > it. Today, the diversity of actual browser behaviors means it is still > possible to fix this mistake, much as the diversity of ways ES3 > implementations were broken made it possible for ES5 to fix many mistakes. > > > The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC > and (because V8 was drafting off JSC) V8 don't nullify all that history. > > On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a > real-world case where this matters, even with Object.create. And I see the > ocap (not just SES) appeal of the fix. > > > Just to be even clearer. This was not a mistake in ES5/5.1 and it is not a > bug. It is a semantics, which as Brendan points out goes all the way back > to ES1. It is also a behavior which makes complete sense from a prototypal > inheritance perspective and can be found in the Self language.
I admit being almost completely ignorant about the history, but I always found this behaviour more than weird. In an ideal world, shouldn't lookup and immutability be two orthogonal mechanisms? That is, either all assignments override (data properties), or none. > The basic idea is that the properties prototype object are shared parts of > all of inheriting child object. Modifying such a shared part by a child, > introduces a local change that is visible to that child (and its children) > so this requires creation of a "own" property on the child. However, > read-only properties can not modified (by normal means, eg assignment) so > there is no need to create a "own" copy. Assigning to an inherited > read-only property or a "own" read-only property should have the same affect > (whether it is ignoring the assignment, throwing, etc.). Allowing > assignment to an inherited read-only property would break the invariant that > that a prototype's readonly property is an immutable value that is shared > among all children of the prototype. Can you elaborate why you are making a special case for immutable properties? Allowing overriding of a writeable property likewise breaks the sharing "invariant". Why should it apply to read-only properties specifically? Your argument, if I understand it correctly, is that immutability is part of the contract of a prototype, and that contract should be inherited by children. Informally, that contract says: Reading this property, through the prototype or any of its children, always returns the same value. Writing to it is an error. But what is the corresponding contract of a mutable property? AFAICT, it is: Reading this property, through the prototype or any of its children, always returns the last value that has been written to it. And that is broken by overriding in the same way as the contract for immutable properties. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
