Fwd: B.3.1 The __proto__ pseudo property

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Fwd: B.3.1 The __proto__ pseudo property

Mark S. Miller-2
Earlier private correspondence with Allen about a line of reasoning I promised to write up and post to es-discuss. I still haven't found the time to write this up, so simply posting this correspondence in the meantime. 

[with a slight bit of editing]


---------- Forwarded message ----------
From: Mark S. Miller <[hidden email]>
Date: Sun, Apr 28, 2013 at 10:52 AM
Subject: Re: B.3.1 The __proto__ pseudo property
To: Allen Wirfs-Brock <[hidden email]>


On Sun, Apr 28, 2013 at 10:41 AM, Allen Wirfs-Brock <[hidden email]> wrote:
(private) 

Do you think we can come to some sort of agreement, as discussed below,  that [[ProtoSetter]] doesn't need to be realm restricted.  Such an agreement would let us write the simplest possible specification of __proto__.

Very timely question. I've discussed this within the other Cajadores and the answer is yes. While the range restriction help security in some ways, it doesn't help a lot, and it actually hurts in other ways. Such simplicity itself is of benefit to security, and weighs in the overall tradeoff. On balance we're better off without it. I'll be posting publicly on this soon. 

 
 It would eliminated having to introduce general object/realm associations into the spec. including whatever unanticipated complications come with them.

We will still need this in ES7 to support weak references, but it is good we can postpone till ES7.


 
 It would also remove all obstacles to having Object.setPrototypeOf which a number of vocal community members would really prefer to have built-in and available rather than having to use __proto__ ugliness.  

Yes. All objections to this disappear. And likewise for having proxies handle trapping proto changes differently from their handling of other changes.

 

I'd really like to get resolution on this so we can get it out of the way once and for all and concentrate on higher leverage spec. work.

What do you think?

Happiness all around !

 

Allen

(PS, If you don't think [[PreventExtensions]] gives SES fine-graned enough control on [[ProtoSetter]] then I'd vastly perfer having a per object [[PreventProtoTampering]] over some sort of realm-based control.)

That would help some. But the pressure for it from our new understanding of the security implications isn't high, and so probably not high enough to cause it to happen. I'm fine without this extra bit.


 




On Apr 23, 2013, at 5:52 PM, Allen Wirfs-Brock wrote:


On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:


...

Regardless, what is so special about the [[ProtoSetter]] operation that it needs to be restricted in this way?  It's just a capability and you know how to control access to capabilities.  You also know how to protect objects from having their [[Prototype]] mutated.  If I have any object, that inherits from a different realm's Object.prototype I can navigate to its constructor property which gives me access to that other realm's, Object.create, Object[[@@create], and all the other Object.* functions.  Why isn't being able to find and  apply some other realms Object.free[ze] just as scary as finding its [[ProtoSetter]]?

SES includes Object.freeze in its set of universally available primordials. Thus, an Object.freeze from a foreign non-SES-secured realm is not a threat since Object.freeze is already universally available to confined ("untrusted") code within the local SES-secured realm.

I expect SES initialization will delete Object.prototype.__proto__ or at least remove its setter. It is conceivable SES will hold the setter off on the side for some special use. But regardless, it will probably[*] deny these powers to confined code within that SES-secured realm. Thus, SES code, including confined code, should be able to safely assume that the [[Prototype]] of its own objects won't be mutated.

When SES code interacts only with SES code, whether intra or inter realm, then this is the end of the story and the cross realm threat is not an issue. But SES objects must be able to maintain their own integrity even when exposed to non-SES objects from other frames. That was impossible for ES5/3, the Caja translator from ES5 to ES3, since Object.freeze was emulated, and thus only enforced for translated code. As of ES5, Object.freeze protects unconditionally (which was why <https://bugzilla.mozilla.org/show_bug.cgi?id=674195> gave Caja so much trouble).

So if SES code should generally be able to assume that its own [[Prototype]]s are stable, we need to preserve the safety of that assumption when objects from a SES-secured realm are exposed to objects from a non-SES-secured realm.

Which you would just do so by make your object's non-extensible, right?  That does more than just limit setting of [[Prototype]] but it does that job too.  I've previously proposed we have an independent per object immutablePrototype state which would be more targeted, but that didn't find any support. 


[*] I say "probably" to hedge my bets. The hard constraint we absolutely require is already guaranteed by ES5: That the [[Prototype]] of a non-extensible object cannot be mutated. Given that, it is possible (though unlikely) that SES will choose to make the setter universally available, in which case you are correct and the inter-realm checks I'm insisting on are for naught. 

Since you've decided it's ok to make Object.freeze, defineProperty, etc. universally available why wouldn't you  also make setPrototypeOf (ie, [[ProtoSetter]]) universally available and just preventExtensions on object you need to protect from that.  It it just the general distaste for __proto__ that most of us share with you?

You haven't yet convinced me that there is actually a need for these realm restrictions on [[ProtoSetter]] and for something seemingly so arbitrary we should really have a strong case for why it is important.  The ES world would be simpler and cleaner within the restrictions and there would be no particular reason for not making Object.setPrototypeOf available as an alternative API for those that prefer it.

Allen







--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: B.3.1 The __proto__ pseudo property

Nathan Wall
>> Do you think we can come to some sort of agreement, as discussed below, 
>> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
>> agreement would let us write the simplest possible specification of 
>> __proto__. 

> Very timely question. I've discussed this within the other Cajadores 
> and the answer is yes. While the range restriction help security in 
> some ways, it doesn't help a lot, and it actually hurts in other 
> ways. Such simplicity itself is of benefit to security, and weighs in 
> the overall tradeoff. On balance we're better off without it. I'll be 
> posting publicly on this soon. 

...

>> It would also remove all obstacles to having Object.setPrototypeOf 
>> which a number of vocal community members would really prefer to have
>> built-in and available rather than having to use __proto__ ugliness.
>
> Yes. All objections to this disappear. And likewise for having proxies
> handle trapping proto changes differently from their handling of other
> changes.


If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].

I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.

Please keep up the discussions around this issue!



[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html     
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller



On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <[hidden email]> wrote:
>> Do you think we can come to some sort of agreement, as discussed below, 
>> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
>> agreement would let us write the simplest possible specification of 
>> __proto__. 

> Very timely question. I've discussed this within the other Cajadores 
> and the answer is yes. While the range restriction help security in 
> some ways, it doesn't help a lot, and it actually hurts in other 
> ways. Such simplicity itself is of benefit to security, and weighs in 
> the overall tradeoff. On balance we're better off without it. I'll be 
> posting publicly on this soon. 

...

>> It would also remove all obstacles to having Object.setPrototypeOf 
>> which a number of vocal community members would really prefer to have
>> built-in and available rather than having to use __proto__ ugliness.
>
> Yes. All objections to this disappear. And likewise for having proxies
> handle trapping proto changes differently from their handling of other
> changes.


If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].

I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.

Agreed on both. The only restriction we need is the one that ES5 already gives us: You can't change the [[Prototype]] of a non-extensible object.

 

Please keep up the discussions around this issue!



[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Andrea Giammarchi-2
fine for non-extensible objects, you might desire to keep a dictionary a dictionary though, allowing properties extensions avoiding hot-swap inheritance

2 options in my mind:

  1. Object.freezeInheritance(generic), setting a [[MutablePrototype]] internal property to false (true by default)
  2. a new native constructor such Dict/Dictionary with immutable [[Prototype]] as exception

I rather prefer a first-like option so that second constructor is easy to implement and any other object can still be used and marked as safe in terms of inheritance.

This would be really nice, IMHO!




On Tue, May 7, 2013 at 12:18 PM, Mark Miller <[hidden email]> wrote:



On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <[hidden email]> wrote:
>> Do you think we can come to some sort of agreement, as discussed below, 
>> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
>> agreement would let us write the simplest possible specification of 
>> __proto__. 

> Very timely question. I've discussed this within the other Cajadores 
> and the answer is yes. While the range restriction help security in 
> some ways, it doesn't help a lot, and it actually hurts in other 
> ways. Such simplicity itself is of benefit to security, and weighs in 
> the overall tradeoff. On balance we're better off without it. I'll be 
> posting publicly on this soon. 

...

>> It would also remove all obstacles to having Object.setPrototypeOf 
>> which a number of vocal community members would really prefer to have
>> built-in and available rather than having to use __proto__ ugliness.
>
> Yes. All objections to this disappear. And likewise for having proxies
> handle trapping proto changes differently from their handling of other
> changes.


If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].

I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.

Agreed on both. The only restriction we need is the one that ES5 already gives us: You can't change the [[Prototype]] of a non-extensible object.

 

Please keep up the discussions around this issue!



[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Allen Wirfs-Brock
In reply to this post by Mark S. Miller
So here is the plan that I'll review at the next TC39 meeting:

1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other Object.* methods in operating on any object, independent of realm association.  

2) Object.prototype.__proto__ is moved back to Annex B. It is defined as an accessor property with attributes {enumerable: true, configurable: true}.  The get and set functions are defined equivalently to Object.setPrototypeOf and Object.getPrototypeOf.  No realm restrictions.  No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) includes "__proto__".

3) __proto__ as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  Object.prototyype.__proto__. 

4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritaqnce]] Proxy handler can't change the observable [[GetInhertance]] result for the proxy object.

Allen

On May 7, 2013, at 12:18 PM, Mark Miller wrote:




On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <[hidden email]> wrote:
>> Do you think we can come to some sort of agreement, as discussed below, 
>> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
>> agreement would let us write the simplest possible specification of 
>> __proto__. 

> Very timely question. I've discussed this within the other Cajadores 
> and the answer is yes. While the range restriction help security in 
> some ways, it doesn't help a lot, and it actually hurts in other 
> ways. Such simplicity itself is of benefit to security, and weighs in 
> the overall tradeoff. On balance we're better off without it. I'll be 
> posting publicly on this soon. 

...

>> It would also remove all obstacles to having Object.setPrototypeOf 
>> which a number of vocal community members would really prefer to have
>> built-in and available rather than having to use __proto__ ugliness.
>
> Yes. All objections to this disappear. And likewise for having proxies
> handle trapping proto changes differently from their handling of other
> changes.


If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].

I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.

Agreed on both. The only restriction we need is the one that ES5 already gives us: You can't change the [[Prototype]] of a non-extensible object.

 

Please keep up the discussions around this issue!



[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller-2
In reply to this post by Mark S. Miller
On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <[hidden email]> wrote:
So here is the plan that I'll review at the next TC39 meeting:

1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other Object.* methods in operating on any object, independent of realm association.  

+1

 

2) Object.prototype.__proto__ is moved back to Annex B.

Since __proto__, unlike __defineGetter__, provides functionality that is otherwise unavailable, all JS platforms will treat it as mandatory whether we put it into Appendix B or the main text. At this point, I think moving this back to Appendix B would be an obviously meaningless gesture


 
It is defined as an accessor property with attributes {enumerable: true, configurable: true}.  The get and set functions are defined equivalently to Object.setPrototypeOf and Object.getPrototypeOf.  No realm restrictions.  No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) includes "__proto__".

+1

 

3) __proto__ as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  Object.prototyype.__proto__. 

I hadn't thought about this irregularity if it appears within a class definition. That aside, +1.

 

4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritaqnce]] Proxy handler can't change the observable [[GetInhertance]] result for the proxy object.

+1. Excellent!

 

Allen

On May 7, 2013, at 12:18 PM, Mark Miller wrote:




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller-2



On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller <[hidden email]> wrote:
On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <[hidden email]> wrote:
So here is the plan that I'll review at the next TC39 meeting:

1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other Object.* methods in operating on any object, independent of realm association.  

+1

 

2) Object.prototype.__proto__ is moved back to Annex B.

Since __proto__, unlike __defineGetter__, provides functionality that is otherwise unavailable, all JS platforms will treat it as mandatory whether we put it into Appendix B or the main text. At this point, I think moving this back to Appendix B would be an obviously meaningless gesture

My "since" is incorrect, as the functionality is available via Object.setPrototypeOf. Nevertheless, I still think this would be a meaningless gesture. OTOH, since it is meaningless, it is also mostly harmless.

 



 
It is defined as an accessor property with attributes {enumerable: true, configurable: true}.  The get and set functions are defined equivalently to Object.setPrototypeOf and Object.getPrototypeOf.  No realm restrictions.  No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) includes "__proto__".

+1

 

3) __proto__ as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  Object.prototyype.__proto__. 

I hadn't thought about this irregularity if it appears within a class definition. That aside, +1.

 

4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritaqnce]] Proxy handler can't change the observable [[GetInhertance]] result for the proxy object.

+1. Excellent!

 

Allen

On May 7, 2013, at 12:18 PM, Mark Miller wrote:




--
    Cheers,
    --MarkM



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Axel Rauschmayer
In reply to this post by Allen Wirfs-Brock
Looks like a very clean solution. The only thing I’m not entirely convinced about is Object.setPrototypeOf()...

... given how one is normally discouraged from using such functionality (=__proto__ as a setter) and
... given that the most frequent use case goes away in ES6 (thanks to it allowing one to subclass built-ins).

Hence, honest question: Does it make sense to expose a new API for something that is mainly used for hacks? If you really needed it, you could retrieve it like this:

const mySetPrototypeOf = Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').set;
// mySetPrototypeOf.call(obj, aProto);
// Alternatively: mySetPrototypeOf = Function.prototype.call.bind(...)

On May 7, 2013, at 22:57 , Allen Wirfs-Brock <[hidden email]> wrote:

So here is the plan that I'll review at the next TC39 meeting:

1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other Object.* methods in operating on any object, independent of realm association.  

2) Object.prototype.__proto__ is moved back to Annex B. It is defined as an accessor property with attributes {enumerable: true, configurable: true}.  The get and set functions are defined equivalently to Object.setPrototypeOf and Object.getPrototypeOf.  No realm restrictions.  No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) includes "__proto__".

3) __proto__ as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  Object.prototyype.__proto__. 

4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritaqnce]] Proxy handler can't change the observable [[GetInhertance]] result for the proxy object.

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Brendan Eich-3
In reply to this post by Mark S. Miller-2
Mark S. Miller wrote:

>
>         2) Object.prototype.__proto__ is moved back to Annex B.
>
>
>     Since __proto__, unlike __defineGetter__, provides functionality
>     that is otherwise unavailable, all JS platforms will treat it as
>     mandatory whether we put it into Appendix B or the main text. At
>     this point, I think moving this back to Appendix B would be an
>     obviously meaningless gesture
>
>
> My "since" is incorrect, as the functionality is available via
> Object.setPrototypeOf. Nevertheless, I still think this would be a
> meaningless gesture. OTOH, since it is meaningless, it is also mostly
> harmless.

Having __proto__ in the main spec be a special form when used as a
property name in an object literal, but relegating
Object.prototype.__proto__ to Annex B, seems inconsistent just on that
basis, too. One place or the other -- main spec or Annex B -- but not both.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller
The special syntax can't go into Annex B; it must remain in the main text. Allen's message agrees with this. I agree that consistency suggests that the property go in the main text, but doesn't demand it. What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win.


On Tue, May 7, 2013 at 9:00 PM, Brendan Eich <[hidden email]> wrote:
Mark S. Miller wrote:

        2) Object.prototype.__proto__ is moved back to Annex B.


    Since __proto__, unlike __defineGetter__, provides functionality
    that is otherwise unavailable, all JS platforms will treat it as
    mandatory whether we put it into Appendix B or the main text. At
    this point, I think moving this back to Appendix B would be an
    obviously meaningless gesture


My "since" is incorrect, as the functionality is available via Object.setPrototypeOf. Nevertheless, I still think this would be a meaningless gesture. OTOH, since it is meaningless, it is also mostly harmless.

Having __proto__ in the main spec be a special form when used as a property name in an object literal, but relegating Object.prototype.__proto__ to Annex B, seems inconsistent just on that basis, too. One place or the other -- main spec or Annex B -- but not both.

/be



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg-4
On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
> What would be gained by
> moving the property alone to Annex B? If nothing, then I think this
> consistency should win.

JavaScript implementations in new or existing eco systems that are not
poisoned by web legacy wouldn't be obliged to support it. It's the
difference between acknowledging web reality and forcing web reality
on everybody.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Allen Wirfs-Brock

On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote:

> On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
>> What would be gained by
>> moving the property alone to Annex B? If nothing, then I think this
>> consistency should win.
>
> JavaScript implementations in new or existing eco systems that are not
> poisoned by web legacy wouldn't be obliged to support it. It's the
> difference between acknowledging web reality and forcing web reality
> on everybody.

+1

The object literal special form could go either place.  I think the O.p properties should be in Annex B and I'm fine with also placing the object literal __proto__ special form there too, based on a consistency argument.

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller
What about your triangle argument?

  Cheers
  --MarkM

On May 8, 2013, at 7:53 AM, Allen Wirfs-Brock <[hidden email]> wrote:

>
> On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote:
>
>> On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
>>> What would be gained by
>>> moving the property alone to Annex B? If nothing, then I think this
>>> consistency should win.
>>
>> JavaScript implementations in new or existing eco systems that are not
>> poisoned by web legacy wouldn't be obliged to support it. It's the
>> difference between acknowledging web reality and forcing web reality
>> on everybody.
>
> +1
>
> The object literal special form could go either place.  I think the O.p properties should be in Annex B and I'm fine with also placing the object literal __proto__ special form there too, based on a consistency argument.
>
> Allen
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Allen Wirfs-Brock

On May 8, 2013, at 8:31 AM, Mark Miller wrote:

> What about your triangle argument?

There is another way:

let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};

Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B box.  That keeps it together with O.p.__proto and leaves room for future, more elegant object literal syntax extensions if we decided we really need them (and we probably won't).

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg-4
On 8 May 2013 17:41, Allen Wirfs-Brock <[hidden email]> wrote:

>
> On May 8, 2013, at 8:31 AM, Mark Miller wrote:
>
>> What about your triangle argument?
>
> There is another way:
>
> let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
>
> Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B box.  That keeps it together with O.p.__proto and leaves room for future, more elegant object literal syntax extensions if we decided we really need them (and we probably won't).

Isn't Object.create the proper alternative to both {__proto__: } and
triangle for objects? What has setPrototypeOf got to do with it? (And
why is that on the table all of a sudden?)

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

David Bruant-5
Le 08/05/2013 16:46, Andreas Rossberg a écrit :

> On 8 May 2013 17:41, Allen Wirfs-Brock <[hidden email]> wrote:
>> On May 8, 2013, at 8:31 AM, Mark Miller wrote:
>>
>>> What about your triangle argument?
>> There is another way:
>>
>> let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
>>
>> Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B box.  That keeps it together with O.p.__proto and leaves room for future, more elegant object literal syntax extensions if we decided we really need them (and we probably won't).
> Isn't Object.create the proper alternative to both {__proto__: } and
> triangle for objects? What has setPrototypeOf got to do with it? (And
> why is that on the table all of a sudden?)
Object.create only creates "normal" objects, not arrays, functions,
dates, etc.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

David Bruant-5
In reply to this post by Andreas Rossberg-4
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
> On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
>> What would be gained by
>> moving the property alone to Annex B? If nothing, then I think this
>> consistency should win.
> JavaScript implementations in new or existing eco systems that are not
> poisoned by web legacy wouldn't be obliged to support it. It's the
> difference between acknowledging web reality and forcing web reality
> on everybody.
What are you saying? V8 releases versions where annoying and ugly de
facto standards are out so that software built on top of Node.js,
MongoDB and other embedders only use a cleaner JS? Awesome! ;-)

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Brandon Benvie-2
In reply to this post by David Bruant-5
On 5/8/2013 9:00 AM, David Bruant wrote:
> Le 08/05/2013 16:46, Andreas Rossberg a écrit :
>> Isn't Object.create the proper alternative to both {__proto__: } and
>> triangle for objects? What has setPrototypeOf got to do with it? (And
>> why is that on the table all of a sudden?)
> Object.create only creates "normal" objects, not arrays, functions,
> dates, etc.

Same is true of `__proto__` in object literals.

The benefit of `__proto__` in literals is the succinctness of it. Using
`Object.create` to create new objects requires using descriptors which
are horribly verbose.


     Circle.prototype = {
       __proto__: Shape,
       constructor: Circle,
       /* etc. */
     };

This becomes much less important with classes.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg-4
In reply to this post by David Bruant-5
On 8 May 2013 18:06, David Bruant <[hidden email]> wrote:

> Le 08/05/2013 08:01, Andreas Rossberg a écrit :
>
>> On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
>>>
>>> What would be gained by
>>> moving the property alone to Annex B? If nothing, then I think this
>>> consistency should win.
>>
>> JavaScript implementations in new or existing eco systems that are not
>> poisoned by web legacy wouldn't be obliged to support it. It's the
>> difference between acknowledging web reality and forcing web reality
>> on everybody.
>
> What are you saying? V8 releases versions where annoying and ugly de facto
> standards are out so that software built on top of Node.js, MongoDB and
> other embedders only use a cleaner JS? Awesome! ;-)

That would be an option -- I'd very much like to move some of these
things behind a flag.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: B.3.1 The __proto__ pseudo property

Andrea Giammarchi-2
I proposed a flag for a reusable setter they told me they have no interest to fragment the language behind these kind of flags ... 

To all: a new syntax is also more suitable for shims/polyfills, something broken/partial implementation of __proto__.set descriptor cannot replace so, as direction, **is** cleaner and easier to adopt/shim

(function(O,p){O[p]||(O[p]=function(o,p){o.__proto__=p;return o})}(Object,'setPrototypeOf'));

Anything any web page could put in without problems (IE10 and lower needs a reference swap and manual implementation of proto through `new` and loop over getOwnPropertyNames descriptors but this is another story plus this is still easier to shim via Object.function instead of a magic property in the Object.prototype)

Otherwise try to deal with broken implementation of Object.getOwnPropertyDescriptor(Object.protototype, '__proto__').set with try/catch to see if poisoned or not and see that as migration/cleaner way to do the same it fails in simplicity and portability.

Side note: I still would like to see in any debugger tons of warnings when anything not standard yet or marked as deprecated in MDN or anywhere else in specs, are shown.

Last, but not least, I am very happy about this direction, you all know that, so **thanks**


On Wed, May 8, 2013 at 9:20 AM, Andreas Rossberg <[hidden email]> wrote:
On 8 May 2013 18:06, David Bruant <[hidden email]> wrote:
> Le 08/05/2013 08:01, Andreas Rossberg a écrit :
>
>> On 8 May 2013 07:10, Mark Miller <[hidden email]> wrote:
>>>
>>> What would be gained by
>>> moving the property alone to Annex B? If nothing, then I think this
>>> consistency should win.
>>
>> JavaScript implementations in new or existing eco systems that are not
>> poisoned by web legacy wouldn't be obliged to support it. It's the
>> difference between acknowledging web reality and forcing web reality
>> on everybody.
>
> What are you saying? V8 releases versions where annoying and ugly de facto
> standards are out so that software built on top of Node.js, MongoDB and
> other embedders only use a cleaner JS? Awesome! ;-)

That would be an option -- I'd very much like to move some of these
things behind a flag.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123