Hello again!
Sorry to reply my own post, but I came to the conclusion that "Self-like
shared part" simply cannot work as an argument (and that not to be able to
override read-only property from the prototype _is_, indeed, an error).
If the "shared part" mind-set was the cornerstone of ES, then this:
foo = { x:4 };
bar = Object.create(foo);
bar.x = 5;
return foo.x;
would yield 5. After all, x is shared part of bar and foo.
But every knows that it yield 4. bar has its own x holding 5, foo has his
own holding 4.
So as for this:
=== Allen Wirfs-Brock wrote ===
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 ...
===
I can only reply with "if the prototype is the shared part as per Self
mindset, you cannot create "own" property at all". In previous example, x is
the shared part. Above statement bar.x = 5 would change foo.x (since it is
the shared x).
So I think the model in Javascript is "fallback delegation" and creation of
own property by Object.defineProperty is not an error; and creation of own
property by assignment should be allowed; and inability to do it is indeed
an error.
Herby
-----Pôvodná správa-----
From: Herby Vojčík
Sent: Tuesday, January 10, 2012 12:09 PM
To: Allen Wirfs-Brock ; Brendan Eich
Cc: Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in
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?
Herby
-----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
...
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).
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
