On Jul 11, 2013, at 9:33 PM, Mark S. Miller wrote:

> Yes, that was intentional. Even though the "__proto__:" looks related to the "__proto__" property initially on Object.prototype, that's only cosmetic. It is now simply part of the object literal syntax, in just the same way that "<|" used to just be special syntax.

Agreed, this is intentional.
> 
> This does seem to leave a hole in the functionality compared to "<|", which is, how do you create a normal property named "__proto__". The answer is the computed property syntax: {["__proto__"]: ...}.
> 
> I don't remember what whether we decided that {"__proto__": ...} means the same thing as {["__proto__"]: ...} or {__proto__: ...}. I think we decided the second, which probably better follows the principle of least surprise. OTOH, the first would have kept JavaScript closes to JSON.

There are various possible issues here.  First, as the spec. is now written {__proto__: ...} and {"__proto__":...} mean exactly the same thing.

Also, I think we still have an issue as to whether or not we want to allow computed property keys (in propName positions) to produce string-valued keys.  When we first were considered computed propNames there were some objections (Ollie Hunt??) to allowing string values.  My recollection was that it potentially forced turning the static checks for things like duplicate property names in object literals into dynamic checks.  My fuzzy recollection is that at that time we decided to disallowed string valued computed propNames  (this is before we temporarily eliminated computed propNames in favor of at-names).  I think there was some discussion of this at the last meeting but I don't feel that we have adequate re-explored  the earlier decisions (?) to not allow string valued propName. So, in the current draft I only allow Symbol valued computed propNames but have it marked as a open issue.

If I turn on string valued computed propNames in the spec, then as currently written {__proto__: ...} and {["__proto__"]: ...} will have the same meaning.   We can, of course, change that but it will significant complicate the delta spec. needed in Annex B for __proto__ in object literals. 


finally, note that the current spec. only assigns special meaning to __proto__ for the production:
     PropertyDefinition: PropertyName : AssignmentExpression

that means that things like:

let __proto__= { };
( {__proto__})

and 

({__proto__ (arg) {}})

produce object with regular own properties named "__proto__".

Allen








> 
> 
> 
> 
> On Thu, Jul 11, 2013 at 9:06 PM, Luke Hoban <lukeh at microsoft.com> wrote:
>   > From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Erik Arvidsson
>   > Yeah, these test all look incorrect to me. IE11 implements an older draft where __proto__ was a magic property.
> 
> That’s right.  Our implementation predates the May spec updates that changed the spec for __proto__.  We will update the test contributions to tests262 to align with the updated spec.
> 
> One question from looking at implications of this change.  Is it intentional that there is no longer a way to remove (or customize) the special handling of __proto__ in object literals?
> 
>     delete Object.prototype.__proto__
>     var p = { y: 34 }
>     var o = { x: 42, __proto__: y }
>     o.y === 34 // was false, now true
> 
> Luke
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130712/1e88552a/attachment-0001.html>

On Jul 11, 2013, at 9:33 PM, Mark S. Miller wrote:

> Yes, that was intentional. Even though the `"__proto__:"` looks related to the `"__proto__"` property initially on `Object.prototype`, that's only cosmetic. It is now simply part of the object literal syntax, in just the same way that `<|` used to just be special syntax.

Agreed, this is intentional.

> This does seem to leave a hole in the functionality compared to `<|`, which is, how do you create a normal property named `__proto__`. The answer is the computed property syntax: `{["__proto__"]: ...}`.
> 
> I don't remember what whether we decided that `{"__proto__": ...}` means the same thing as `{["__proto__"]: ...}` or `{__proto__: ...}`. I think we decided the second, which probably better follows the principle of least surprise. OTOH, the first would have kept JavaScript closes to JSON.

There are various possible issues here.  First, as the spec. is now written `{__proto__: ...}` and `{"__proto__":...}` mean exactly the same thing.

Also, I think we still have an issue as to whether or not we want to allow computed property keys (in propName positions) to produce string-valued keys.  When we first were considered computed propNames there were some objections (Ollie Hunt??) to allowing string values.  My recollection was that it potentially forced turning the static checks for things like duplicate property names in object literals into dynamic checks.  My fuzzy recollection is that at that time we decided to disallowed string valued computed propNames  (this is before we temporarily eliminated computed propNames in favor of at-names).  I think there was some discussion of this at the last meeting but I don't feel that we have adequate re-explored  the earlier decisions (?) to not allow string valued propName. So, in the current draft I only allow Symbol valued computed propNames but have it marked as a open issue.

If I turn on string valued computed propNames in the spec, then as currently written `{__proto__: ...}` and `{["__proto__"]: ...}` will have the same meaning.   We can, of course, change that but it will significant complicate the delta spec. needed in Annex B for `__proto__` in object literals. 


finally, note that the current spec. only assigns special meaning to `__proto__` for the production:

     PropertyDefinition: PropertyName : AssignmentExpression

that means that things like:

```js
let __proto__= { };
( {__proto__})
```

and 

```js
({__proto__ (arg) {}})
```

produce object with regular own properties named `"__proto__"`.

On Jul 11, 2013, at 9:33 PM, Mark S. Miller wrote:

> Yes, that was intentional. Even though the `"__proto__:"` looks related to the `"__proto__"` property initially on `Object.prototype`, that's only cosmetic. It is now simply part of the object literal syntax, in just the same way that `<|` used to just be special syntax.

Agreed, this is intentional.

> This does seem to leave a hole in the functionality compared to `<|`, which is, how do you create a normal property named `__proto__`. The answer is the computed property syntax: `{["__proto__"]: ...}`.
> 
> I don't remember what whether we decided that {"__proto__": ...} means the same thing as {["__proto__"]: ...} or {__proto__: ...}. I think we decided the second, which probably better follows the principle of least surprise. OTOH, the first would have kept JavaScript closes to JSON.

There are various possible issues here.  First, as the spec. is now written {__proto__: ...} and {"__proto__":...} mean exactly the same thing.

Also, I think we still have an issue as to whether or not we want to allow computed property keys (in propName positions) to produce string-valued keys.  When we first were considered computed propNames there were some objections (Ollie Hunt??) to allowing string values.  My recollection was that it potentially forced turning the static checks for things like duplicate property names in object literals into dynamic checks.  My fuzzy recollection is that at that time we decided to disallowed string valued computed propNames  (this is before we temporarily eliminated computed propNames in favor of at-names).  I think there was some discussion of this at the last meeting but I don't feel that we have adequate re-explored  the earlier decisions (?) to not allow string valued propName. So, in the current draft I only allow Symbol valued computed propNames but have it marked as a open issue.

If I turn on string valued computed propNames in the spec, then as currently written {__proto__: ...} and {["__proto__"]: ...} will have the same meaning.   We can, of course, change that but it will significant complicate the delta spec. needed in Annex B for __proto__ in object literals. 


finally, note that the current spec. only assigns special meaning to __proto__ for the production:
     PropertyDefinition: PropertyName : AssignmentExpression

that means that things like:

let __proto__= { };
( {__proto__})

and 

({__proto__ (arg) {}})

produce object with regular own properties named "__proto__".