Re: ES6 doesn't need opt-in

[Herby Vojčík]

Hello,

so I looked up the spec. I never remembered the exact [[Put]], [[Get]] 
machinery but now it is obvious that ES has in fact "amalgamate" mental 
model of "shared-part always-use-setter-for-assignment having shadowing 
default setter" (well, I figured that out before looking at spec by just 
reverse engineering actual state, but then I looked up). So, really, 
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake is 
not an error. But so is not the Object.defineProperty that is able to create 
own property. Assignment is assignment, setting own property is different, 
low-level thing. At least as I see it.


Herby

P.S.: I would bet 99% of developers thinks the model is in fact "fallback 
delegation". :-/ It is simpler model that works most of the time. Always 
write locally, always read locally and then look up the prototype chain.


-Pôvodná správa- 
From: Herby Vojčík

Sent: Tuesday, January 10, 2012 6:39 PM
To: John J Barton
Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in

...

So, to sum, either we have "self shared part" mental model, in which foo.x
is shared part of bar.x, but then you _cannot_ have "own" shadowing
preoperties and plain "bar.x = 5" behaviour of current implementations is
inconsistent;
or we have "own overlaying properties with property chain search" (which I
dubbed "fallback delegation") mental model, in which bar.x = 5 make perfect
sense, but alas not only in writable foo.x scenario, but every time (even if
foo.x does not exist or if foo.x is read-only), so prohibiting it for
read-only foo.x is inconstitency.

So, we have inconsistency anyway, the question is which one to fix (and I am
pretty sure not the first one).

Herby

P.S.: Yes, you can construct a complicated mental model amalgamate, like
"shared part with explicit allowance for per-child-subtree-shadowing". Let
someone like Allen or Brendan tells exactly what is the mental model, then.
It seems none of simple, consistent models of "shared part" or "fallback
delegate" is true.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

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

jjb
===

Yes. It is correct. This is what the subdiscussion is about, is it not? 
Allen said it is not an error to prohibit bar.x = 5 if foo.x is read-only 
and argument that foo.x (foo is parent, bar is child) is shared part.


And I'm saying it is falsy to argument with "x is shared part of bar through 
parent foo" because then bar.x - 5 must change foo.x but it does not. 
Creating "own" properties is breaking "shared part". Since there are "own" 
shadowing properites, the model must not be "shared part", but something 
other, which allows "own", shadowing properties. In such a model it makes 
perfect sense to allow bar.x = 5 without regard to foo.x readonliness. 
Prohibiting it is in fact something that is inconsistent with the mental 
model.


So, to sum, either we have "self shared part" mental model, in which foo.x 
is shared part of bar.x, but then you _cannot_ have "own" shadowing 
preoperties and plain "bar.x = 5" behaviour of current implementations is 
inconsistent;
or we have "own overlaying properties with property chain search" (which I 
dubbed "fallback delegation") mental model, in which bar.x = 5 make perfect 
sense, but alas not only in writable foo.x scenario, but every time (even if 
foo.x does not exist or if foo.x is read-only), so prohibiting it for 
read-only foo.x is inconstitency.


So, we have inconsistency anyway, the question is which one to fix (and I am 
pretty sure not the first one).


Herby

P.S.: Yes, you can construct a complicated mental model amalgamate, like 
"shared part with explicit allowance for per-child-subtree-shadowing". Let 
someone like Allen or Brendan tells exactly what is the mental model, then. 
It seems none of simple, consistent models of "shared part" or "fallback 
delegate" is true.


-Pôvodná správa- 
From: John J Barton

Sent: Tuesday, January 10, 2012 5:54 PM
To: Herby Vojčík
Cc: Allen Wirfs-Brock ; Brendan Eich ; Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in




On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík  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

Re: ES6 doesn't need opt-in

[John J Barton]

On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík  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@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 9 January 2012 21:41, Allen Wirfs-Brock  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
> .
> 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

Re: ES6 doesn't need opt-in

[Herby Vojčík]

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

Re: ES6 doesn't need opt-in

[Herby Vojčík]

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



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


Allen










___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 9 January 2012 21:37, Gavin Barraclough  wrote:
> On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote:
>>
>> I think the state machine is over-complicating things. What it boils
>> down to is that we are defining a new language, ES6-proper (or
>> informally ES6 for short). It overlaps with ES5 but does not include
>> it (e.g. throws out `with'). Then your "state machine" simply says,
>> declaratively:
>>
>> - If a program is ES5 but not ES6, treat as ES5.
>> - If a program is ES6 but not ES5, treat as ES6.
>> - If a program is both ES5 and ES6, with identical semantics, treat as
>> ES6 (although it doesn't matter).
>> - If a program is both ES5 and ES6, with different semantics, treat as
>> ES5 (for compatibility).
>> - If a program is neither ES5 nor ES6, it's an error (obviously).
>
> If the a program is both ES5 and ES6 with identical semantics, then
> presumably we could equally treat it as ES5 with no behavior change?
> If so, couldn't this be stated in a much simpler fashion:
>
> - If a program is ES5, treat as ES5.
> - If a program is not ES5 but is ES6, treat as ES6.
> - If a program is neither ES5 nor ES6, it's an error (obviously).

Indeed, that is even more to the point.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

How to denote generator methods?

[Herby Vojčík]

Hi,

for a function, you can instead of

 method: function (args) { body },

use the convenient (and non-enumerating)

 method (args) { body }

in literal / class.

But for a generator


 gen: function* (args) { body }

what can you use to create a generator method?
Would

 *gen (args) { body }

be possible?

Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss