ES6 doesn't need opt-in

John J Barton johnjbarton at johnjbarton.com
Tue Jan 10 08:54:35 PST 2012


On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík <herby at mailbox.sk> wrote:

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

In your example |foo| is not an inheriting child object. It is the parent.

jjb



> 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 at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120110/b6bdf72a/attachment.html>


More information about the es-discuss mailing list