ES6 doesn't need opt-in

Herby Vojčík herby at
Tue Jan 10 03:09:05 PST 2012

This is interesting issue. There is a subtle difference between "prototype 
chain is the shared part" Self mindset and the "prototype chain is fallback 
delegation" mindset. Though I knew of Self and knew it had an impact on 
Javascript creation, I had always an impression that in Javascript (having 
become ECMAScript) it was the latter, that is the philosophy is that child 
can override the default from prototype chain.

So what is the actual philosophy of ES prototype chain?


-----Pôvodná správa----- 
From: Allen Wirfs-Brock
Sent: Monday, January 09, 2012 9:41 PM
To: Brendan Eich
Cc: Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in

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

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.

If there was a mistake in designing ES5, it was allowing 
Object.defineOwnProperty to create child properties that over-ride inherited 
read-only data properties.  This broke an invariant that previously existed 
in the language but this invariant  was already violated by some pre-ES5 
clause 15 objects, (eg the writability of the prototype property of some 
children of Function.prototype).  However, I think the ES5 decision was 
probably the right one given the legacy clause 15 usages and the overall 
reflective nature of defineOwnProperty).


es-discuss mailing list
es-discuss at 

More information about the es-discuss mailing list