B.3.1 The __proto__ pseudo property

Mark S. Miller erights at google.com
Sun Apr 21 15:11:23 PDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/bdc6be4e/attachment.html>


More information about the es-discuss mailing list