On Sun, Apr 21, 2013 at 8:41 PM, Brendan Eich <bren...@mozilla.com> wrote:
> So as my last post said, if there's no observable difference in the field
> in switching from [[Put]] to [[SetInheritance]], then you and Mark are
> right, and we can do that in ES6 without fear of breaking any code.
>
> This change *is* observable in ES6, though. That's why I summoned Mark: to
> make sure there's no SES issue with setting _ab initio_ the [[Prototype]]
> (or now I guess it's called [[Inheritance]]) of a fresh object created via
> an object literal.
Given that the programmer is aware of this syntactic special case, I don't
think there's a problem. As someone else commented, it seems equivalent to
what you express otherwise using Object.create. I see a few potential
problems:
1) If a programmer is unaware of the syntax, he might innocently write this
(implausible) or innocently read this and misinterpret its meaning (much
more plausible). It adds yet another special case to a language already
burdened with them.
2) If a code generating program generates an object literal without
checking for the "__proto__" special case in its input, it can generate
code that does not mean what it intends. This would be an encoding error
that's structurally similar to some encoding errors that lead to XSS, but
is much less likely to do so in this case.
3) If we extend object literals with the computed name expression
square-bracket syntax, consider
{ [ e ]: .... }
where e is an expression that evaluates to the string "__proto__". This
*must not* fall into the equivalent of the syntactic special case. To do so
is to move the encoding error of #2 from code-generating programs to
regular JS reflective programs.
My sense is that we can live with #1 and #2, but these are worth debating.
If the computed case of #3 were similarly special cased though, my sense is
we could not live with that.
>
>
> Allen Wirfs-Brock wrote:
>
>> Triangle died for several reasons, and I'm surprised to hear it here.
>>> Grinding an axe?
>>>
>>
>> Not at all! You frequently have said that standardizing __proto__ takes
>> the wind out of other features that support various use cases of
>> defining/manipulating an object's [[Prototype]]. One of those features is
>> using an object literal as a way to declaratively describe an object that
>> inherits from something other than Object.prototype (including null).
>>
>
> The argument is that anyone code that deletes Object.prototype.__proto__
> should not affect object literals wiring up from-birth inheritance is fair.
> I shouldn't have mentioned axes, sorry.
>
> The only issue is the ES6 => SES one. If Mark's happy, then we are done as
> far as this [[Put]] vs. [[SetInheritance]] argument goes.
>
As long as we're agreed on #3 being exempt from that special case, I'm
happy.
>
> The quoted vs. unquoted difference is horrifying to me, I threw up in my
> mouth a little. More on that elsewhere.
Glad you share my misery over that one!
Fortunately, answering your previous question, I realized that we have a
much safer escape hatch, even though we would lose the correspondence with
JSON of the previous proposal:
{ [ "__proto__" ]: .... }
defines a normal property named "__proto__" with no special case. As I
write above, I think we're forced into this anyway by other considerations.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
