Any reason why __proto__ is not a well known symbol?

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

Any reason why __proto__ is not a well known symbol?

JD Isaacks
I know ES2015 formally made the `__proto__` property a way to access/set an object's internal `[[Prototype]]` property.

Is there any reason why this wasn't spec'd as a well known symbol such as `@@__proto__`. It just seems like it would line up well with other modifiers like `@@iterator`, `@@species`, etc.

Being that it was not formally spec'd it shouldn't have broke backwards compatibility either.

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

Re: Any reason why __proto__ is not a well known symbol?

Tab Atkins Jr.
On Mon, Feb 15, 2016 at 8:34 PM, JD Isaacks <[hidden email]> wrote:
> I know ES2015 formally made the `__proto__` property a way to access/set an
> object's internal `[[Prototype]]` property.
>
> Is there any reason why this wasn't spec'd as a well known symbol such as
> `@@__proto__`. It just seems like it would line up well with other modifiers
> like `@@iterator`, `@@species`, etc.

It was specified before symbols existed, and all implementations do it
as a string property.  If we were reinventing it today it would either
be a symbol or something in the MOP, but are hands are tied by legacy.

> Being that it was not formally spec'd it shouldn't have broke backwards
> compatibility either.

Backwards compat has nothing to do with specs, and everything to do
with existing implementations.  Multiple implementations agreed on
__proto__, so our choice was either to leave it unstandardized or spec
what the browsers did.

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

Re: Any reason why __proto__ is not a well known symbol?

Coroutines
On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[hidden email]> wrote:

> It was specified before symbols existed, and all implementations do it
> as a string property.  If we were reinventing it today it would either
> be a symbol or something in the MOP, but are hands are tied by legacy.
>
>> Being that it was not formally spec'd it shouldn't have broke backwards
>> compatibility either.
>
> Backwards compat has nothing to do with specs, and everything to do
> with existing implementations.  Multiple implementations agreed on
> __proto__, so our choice was either to leave it unstandardized or spec
> what the browsers did.

Is there a migration to make it a Symbol in ES7?  (ignorant question?)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any reason why __proto__ is not a well known symbol?

Kevin Smith
Is there a migration to make it a Symbol in ES7?  (ignorant question?)

Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it.



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

Re: Any reason why __proto__ is not a well known symbol?

JD Isaacks
Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it.

Not if you are trying to set in an object literal.

On Tue, Feb 16, 2016 at 12:17 AM, Kevin Smith <[hidden email]> wrote:
Is there a migration to make it a Symbol in ES7?  (ignorant question?)

Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it.




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

Re: Any reason why __proto__ is not a well known symbol?

Tab Atkins Jr.
In reply to this post by Coroutines
On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <[hidden email]> wrote:

> On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[hidden email]> wrote:
>> It was specified before symbols existed, and all implementations do it
>> as a string property.  If we were reinventing it today it would either
>> be a symbol or something in the MOP, but are hands are tied by legacy.
>>
>>> Being that it was not formally spec'd it shouldn't have broke backwards
>>> compatibility either.
>>
>> Backwards compat has nothing to do with specs, and everything to do
>> with existing implementations.  Multiple implementations agreed on
>> __proto__, so our choice was either to leave it unstandardized or spec
>> what the browsers did.
>
> Is there a migration to make it a Symbol in ES7?  (ignorant question?)

There's a lot of code in the wild that uses __proto__ and depends on
it.  We can't remove it until/unless that changes (it won't, at least
not in the near future), and while we have __proto__, there's no
reason to have anything else.

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

Re: Any reason why __proto__ is not a well known symbol?

Andrea Giammarchi-2
In reply to this post by JD Isaacks
`Object.getPrototypeOf` and `Object.setPrototypeOf` works everywhere, including null objects, as long as extension hasn't been prevented ( `Objet.freeze`, `Object.seal` or `Object.preventExtension` )

It's `__proto__` accessor that indeed doesn't work as expected in null object, where it's always stored as key.

```js
var dict = Object.create(null);
dict.__proto__ = [];

Object.keys(dict); // ["__proto__"]
dict instanceof Array; // false

Object.setPrototypeOf(dict, []);
dict instanceof Array; // true
```

However, if you want the key `"__proto__"` you can specify it at string at runtime `{"__proto__": "this way"}` or use `Object.defineProperty(obj, "__proto__", {value: "any"})`

Regards



On Tue, Feb 16, 2016 at 5:47 AM, JD Isaacks <[hidden email]> wrote:
Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it.

Not if you are trying to set in an object literal.

On Tue, Feb 16, 2016 at 12:17 AM, Kevin Smith <[hidden email]> wrote:
Is there a migration to make it a Symbol in ES7?  (ignorant question?)

Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to do it.




_______________________________________________
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: Any reason why __proto__ is not a well known symbol?

Dean Landolt
In reply to this post by Tab Atkins Jr.


On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <[hidden email]> wrote:
On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <[hidden email]> wrote:
> On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[hidden email]> wrote:
>> It was specified before symbols existed, and all implementations do it
>> as a string property.  If we were reinventing it today it would either
>> be a symbol or something in the MOP, but are hands are tied by legacy.
>>
>>> Being that it was not formally spec'd it shouldn't have broke backwards
>>> compatibility either.
>>
>> Backwards compat has nothing to do with specs, and everything to do
>> with existing implementations.  Multiple implementations agreed on
>> __proto__, so our choice was either to leave it unstandardized or spec
>> what the browsers did.
>
> Is there a migration to make it a Symbol in ES7?  (ignorant question?)

There's a lot of code in the wild that uses __proto__ and depends on
it.  We can't remove it until/unless that changes (it won't, at least
not in the near future), and while we have __proto__, there's no
reason to have anything else.


Is it too late to remove support for dunder-__proto__ strictly within module contexts? This might introduce a bit of a refactor hazard when pulling old code into modules, but it's only the static `obj.__proto__` usage that has any effect so this can be handled pretty easily with linter warnings. Or it could be contextually reserved and throw an early exception.

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

Re: Any reason why __proto__ is not a well known symbol?

Andrea Giammarchi-2
As much as Id love to see dunder-`__proto__` burn away from any future specification, there are at least two use cases I do like in terms of simplification:
  1. to shortcut literals with enumerable, configurable, and writable own properties that extend known objects (or null) such `{__proto__:null, key: 'value'}` . This cannot be compared with the tedious `Object.create(null, {key: {enumerable: true, writable: true, configurable: true, value: 'value'}})`
  2. to explain inheritance through the console or to people in general, using it only as virtual-read-only reference to the inheritance chain
While the first point will be simplified a lot thanks to `Object.getOwnPropertyDescriptors` so that the literal form can be still used via `Object.create(null, Object.getOwnPropertyDescriptors({key: 'value'}))` the second point is still interesting but, like I've mentioned, usable as abstract concept too that doesn't need to be specd' as magic behavior.

Just my 2 cents

Best Regards





On Tue, Feb 16, 2016 at 4:00 PM, Dean Landolt <[hidden email]> wrote:


On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <[hidden email]> wrote:
On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <[hidden email]> wrote:
> On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[hidden email]> wrote:
>> It was specified before symbols existed, and all implementations do it
>> as a string property.  If we were reinventing it today it would either
>> be a symbol or something in the MOP, but are hands are tied by legacy.
>>
>>> Being that it was not formally spec'd it shouldn't have broke backwards
>>> compatibility either.
>>
>> Backwards compat has nothing to do with specs, and everything to do
>> with existing implementations.  Multiple implementations agreed on
>> __proto__, so our choice was either to leave it unstandardized or spec
>> what the browsers did.
>
> Is there a migration to make it a Symbol in ES7?  (ignorant question?)

There's a lot of code in the wild that uses __proto__ and depends on
it.  We can't remove it until/unless that changes (it won't, at least
not in the near future), and while we have __proto__, there's no
reason to have anything else.


Is it too late to remove support for dunder-__proto__ strictly within module contexts? This might introduce a bit of a refactor hazard when pulling old code into modules, but it's only the static `obj.__proto__` usage that has any effect so this can be handled pretty easily with linter warnings. Or it could be contextually reserved and throw an early exception.

_______________________________________________
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: Any reason why __proto__ is not a well known symbol?

Coroutines
In reply to this post by Dean Landolt
On Tue, Feb 16, 2016 at 8:00 AM, Dean Landolt <[hidden email]> wrote:

> Is it too late to remove support for dunder-__proto__ strictly within module
> contexts? This might introduce a bit of a refactor hazard when pulling old
> code into modules, but it's only the static `obj.__proto__` usage that has
> any effect so this can be handled pretty easily with linter warnings. Or it
> could be contextually reserved and throw an early exception.

I dunno, it just seems odd to cement it forever in JS when you can
even feature-test for it (vs using a Symbol).  At some point I really
just expect people to keep up with with things and not be a Python 2
lazy person :D  I hope ES7 makes breaking changes all over the place
:p
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any reason why __proto__ is not a well known symbol?

Boris Zbarsky
On 2/16/16 12:01 PM, Coroutines wrote:
>I hope ES7 makes breaking changes all over the place

Do you also hope ES7 never ships in any web browsers?

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

Re: Any reason why __proto__ is not a well known symbol?

Leo Balter
In reply to this post by Andrea Giammarchi-2
For the sake of consistency and compatibility, instead of the following example:

`{__proto__:null, key: 'value'}`

Let this key be represented by a `Symbol.proto` or `Symbol.toPrototype`. This would work fine to avoid using Object.create getting descriptors or along Object.assign.

unless TC39 want to represent other Symbols within the `__` notation, `__proto__` should be left alone and die in the first moment it's possible.
 

On Tue, Feb 16, 2016 at 2:45 PM, Andrea Giammarchi <[hidden email]> wrote:
As much as Id love to see dunder-`__proto__` burn away from any future specification, there are at least two use cases I do like in terms of simplification:
  1. to shortcut literals with enumerable, configurable, and writable own properties that extend known objects (or null) such `{__proto__:null, key: 'value'}` . This cannot be compared with the tedious `Object.create(null, {key: {enumerable: true, writable: true, configurable: true, value: 'value'}})`
  2. to explain inheritance through the console or to people in general, using it only as virtual-read-only reference to the inheritance chain
While the first point will be simplified a lot thanks to `Object.getOwnPropertyDescriptors` so that the literal form can be still used via `Object.create(null, Object.getOwnPropertyDescriptors({key: 'value'}))` the second point is still interesting but, like I've mentioned, usable as abstract concept too that doesn't need to be specd' as magic behavior.

Just my 2 cents

Best Regards





On Tue, Feb 16, 2016 at 4:00 PM, Dean Landolt <[hidden email]> wrote:


On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <[hidden email]> wrote:
On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <[hidden email]> wrote:
> On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[hidden email]> wrote:
>> It was specified before symbols existed, and all implementations do it
>> as a string property.  If we were reinventing it today it would either
>> be a symbol or something in the MOP, but are hands are tied by legacy.
>>
>>> Being that it was not formally spec'd it shouldn't have broke backwards
>>> compatibility either.
>>
>> Backwards compat has nothing to do with specs, and everything to do
>> with existing implementations.  Multiple implementations agreed on
>> __proto__, so our choice was either to leave it unstandardized or spec
>> what the browsers did.
>
> Is there a migration to make it a Symbol in ES7?  (ignorant question?)

There's a lot of code in the wild that uses __proto__ and depends on
it.  We can't remove it until/unless that changes (it won't, at least
not in the near future), and while we have __proto__, there's no
reason to have anything else.


Is it too late to remove support for dunder-__proto__ strictly within module contexts? This might introduce a bit of a refactor hazard when pulling old code into modules, but it's only the static `obj.__proto__` usage that has any effect so this can be handled pretty easily with linter warnings. Or it could be contextually reserved and throw an early exception.

_______________________________________________
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



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

Re: Any reason why __proto__ is not a well known symbol?

Allen Wirfs-Brock
In reply to this post by Dean Landolt

On Feb 16, 2016, at 8:00 AM, Dean Landolt <[hidden email]> wrote:

s it too late to remove support for dunder-proto strictly within module contexts? This might introduce a bit of a refactor hazard when pulling old code into modules, but it's only the static `obj.__proto__` usage that has any effect so this can be handled pretty easily with linter warnings. Or it could be contextually reserved and throw an early exception.

dunder proto as built-in property of Object.prototype is mode/syntactic context independent.  It can be restricted in that manner.

On the other hand, the meaning of dunder-proto within an object literal is specified [1] as a syntactic form.  So, in theory, its use could be restricted to specific syntactic contexts such as strict mode or not in a Module. ES2015 did not apply any such restrictions and given that strict mode and dunder-proto has co-existed in browsers since ES5 it’s unlike the we could purge it from strict mode.   Making it illegal in Modules might still be feasible. It would probably take some some strong advocation within TC39 to make it happen. 

Allen



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

Re: Any reason why __proto__ is not a well known symbol?

Bergi
In reply to this post by Andrea Giammarchi-2
Andrea Giammarchi wrote:

> As much as Id love to see dunder-`__proto__` burn away from any future
> specification,

Before doing that, we should burn it away from everyones code :-)

> there are at least two use cases I do like in terms of
> simplification:
>
>     1. to shortcut literals with enumerable, configurable, and writable own
>     properties that extend known objects (or null) such `{__proto__:null, key:
>     'value'}` . This cannot be compared with the tedious `Object.create(null,
>     {key: {enumerable: true, writable: true, configurable: true, value:
>     'value'}})`

The much simpler solution to that would be `Object.setPrototypeOf({key:
'value'}, null)` (which also returns the object). Admittedly, putting
the prototype in the end is a bit awkward, and `__proto__` in a literal
probably simplifies creation optimisations.
The way to overcome this would be to promote the [prototype `<|`
operator](http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator), which
I would love to see in ES8. Anyone up for making an up-to-date proposal?

>     2. to explain inheritance through the console or to people in general,
>     using it only as virtual-read-only reference to the inheritance chain

I wholeheartedly recommend to use the term *[[prototype]]* (in italics
or color) for this, and call it out as what it is: an **internal**
property. Don't teach people that `__proto__` is a magical property - it
is not (causing confusion); and they only will start or continue using
it in new code.
Even in code examples, or simple demonstrations, use `console.log(x,
Object.getPrototypeOf(x))` over `console.log(x, x.__proto__)`.

Regards,
  Bergi

PS: Ceterum censeo __proto__ esse delendum :-)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any reason why __proto__ is not a well known symbol?

Andrea Giammarchi-2
You break an open door and I was the one proposing `setPrototypeOf` and to kill `__proto__` long time ago but about this:

Don't teach people that `__proto__` is a magical property - it is not (causing confusion); and they only will start or continue using it in new code.

I'm afraid my recent book is the only one I know that avoided dunder-proto.
Most other articles/books about "modern JS" all use and/or describe `__proto__`

So we need people to stop using it, and modules would be a great opportunity to at least warn the community, and we need to stop talking about it in modern published online and offline books.

Best Regards



On Tue, Feb 16, 2016 at 9:00 PM, Bergi <[hidden email]> wrote:
Andrea Giammarchi wrote:

As much as Id love to see dunder-`__proto__` burn away from any future
specification,

Before doing that, we should burn it away from everyones code :-)

there are at least two use cases I do like in terms of
simplification:

    1. to shortcut literals with enumerable, configurable, and writable own
    properties that extend known objects (or null) such `{__proto__:null, key:
    'value'}` . This cannot be compared with the tedious `Object.create(null,
    {key: {enumerable: true, writable: true, configurable: true, value:
    'value'}})`

The much simpler solution to that would be `Object.setPrototypeOf({key: 'value'}, null)` (which also returns the object). Admittedly, putting the prototype in the end is a bit awkward, and `__proto__` in a literal probably simplifies creation optimisations.
The way to overcome this would be to promote the [prototype `<|` operator](http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator), which I would love to see in ES8. Anyone up for making an up-to-date proposal?

    2. to explain inheritance through the console or to people in general,
    using it only as virtual-read-only reference to the inheritance chain

I wholeheartedly recommend to use the term *[[prototype]]* (in italics or color) for this, and call it out as what it is: an **internal** property. Don't teach people that `__proto__` is a magical property - it is not (causing confusion); and they only will start or continue using it in new code.
Even in code examples, or simple demonstrations, use `console.log(x, Object.getPrototypeOf(x))` over `console.log(x, x.__proto__)`.

Regards,
 Bergi

PS: Ceterum censeo __proto__ esse delendum :-)

_______________________________________________
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