B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Apr 21 15:16:05 PDT 2013


Off Topic: it's really funny that it took 10 years to teach people how
inheritance works in JS and today there's some legacy that instead of
constructors uses their objects or just objects as prototype so that
{__proto__:whatever} is considered a used pattern.

If the most common case is {__proto__:null} though, I would not spend time
explaining an exception in the syntax instead of keep promoting
Object.create(null); which is the way to go (it was at ES5 time at least)

Regards


On Sun, Apr 21, 2013 at 3:11 PM, Mark S. Miller <erights at google.com> wrote:

> On Sun, Apr 21, 2013 at 1:37 PM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> Allen Wirfs-Brock wrote:
>>
>>> On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
>>> >  You don't want that to affect object literals evaluated in the same
>>> realm after such a deletion. Why not?
>>>
>>> Why should it?
>>>
>>
>> ... because it did in ES5-conforming implementations that support
>> __proto__ as a de-facto standard *and* allow delete
>> Object.prototype.__proto__.
>>
>>
>>     We already used the existence of {__proto__: whatever} got rid of<|
>>> as declarative syntax for defining an object literal with a [[Prototype]]
>>> other than object prototype.  Making {__proto__: whatever}  only work some
>>> of the times means it isn't a reliable declarative syntax.
>>>
>>
>> What?
>>
>> Mark insists on delete Object.prototype.__proto__ making the magic go
>> away. (Summoning Mark.)
>>
>
> ;)
>
> I agree with the spirit of what Allen is saying, but I'm not sure if I
> agree on the particulars. {__proto__: whatever, ....} is special syntax
> sets the [[Prototype]] property of the resulting object to the value of
> whatever. This syntax does not invoke [[Put]] anything and has no
> relationship (beyond evocative similarity) to the property
> Object.prototype.__proto__, whether it has been deleted or not. This
> special status does not apply to obj.__proto__ = whatever, nor to
> object.__proto__. Those two do a simple [[Set]] (or, in ES5 terms, [[Put]])
> and [[Get]] respectively, and so do depend on the existence and nature of
> an inherited __proto__ property.
>
>
>
>>
>> Triangle died for several reasons, and I'm surprised to hear it here.
>> Grinding an axe?
>
>
> No, Allen's point here is valid. Only if {__proto__: ....} is honored as
> special syntax do we no longer gain enough additional benefit from triangle
> for it to be worth the cost.
>
>
>
>>
>>
>>     Why would we want to do that?  There is arguably a good motivation
>>> wanting disable the ability to dynamically __proto__ modify arbitrary
>>> pare-existing objects. But what is the motifacation for doing that on newly
>>> created objects?
>>>
>>
>> I will tag Mark in here, but first make my own move:
>>
>> Answer: because the clear way to implement this in ES5-conforming
>> implementations that support __proto__ is to call [[Put]] not
>> [[DefineOwnProperty]] if the name of the property being initialized in the
>> object literal is '__proto__', and that's what engines implement.
>>
>> That makes a new de-facto standard, which you should not be wasting
>> energy trying to break!
>
>
> It sounds like you agree that defining {__proto__: whatever} in terms of
> [[Put]] (aka [[Set]]) causes problems. So let's not do that. We don't
> actually need to define it in terms of [[DefineOwnProperty]] either. Like
> triangle, this happens when we create a *new* object, so we can just create
> a new object with its [[Prototype]] already initialized to whatever.
>
>
>
>>
>>
>>  SpiderMonkey at least goes out of its way to do [[Set]] (let's call it)
>>>> not [[DefineOwnProperty]] for 'o = {__proto__: 42}', so why wouldn't
>>>> [[Set]] create a fresh property, seeing nothing on Object.prototype named
>>>> '__proto__' with a setter to run?
>>>>
>>>
>>> Because the semantics that says you can't use [[DefineOwnProperty]] may
>>> say to go out of the way to do something else.
>>>
>>
>> Too late, ES5+reality happened. You are now proposing to break the web,
>> at the limit. JS implementors will not go for that, so you are wasting your
>> time.
>
>
> For all parties, some examples of legacy uses of {__proto__: ....},
> whether hypothetical or observed, would help a lot. I doubt the stance
> "special literal syntax for initializing [[Prototype]] without using either
> [[Put]]/[[Set]] nor [[DefineOwnProperty]]" would be incompatible with web
> reality.
>
>
>>
>>     It my strawman spec. it says use [[SetInhertiance]] rather than
>>> [[Put]].  Either is a special case semantics and [[SetInheritance]] is a
>>> much more direct expression of the likely user intent.
>>>
>>
>> Direct, schmirect.
>>
>> This is about compatibility and consistency, not what you can edit into a
>> draft. Please reconsider. Must we put this on the next meeting's agenda?
>>
>> /be
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<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/20130421/2440ac55/attachment-0001.html>


More information about the es-discuss mailing list