Lecture series on SES and capability-based security by Mark Miller

Mark S. Miller erights at google.com
Tue Nov 8 20:57:58 PST 2011


http://www.google.com/support/forum/p/Google+Docs/thread?tid=0cd4a00bd4aef9e4
But yes. Because the difference would be silent, I'm skeptical too.

On Tue, Nov 8, 2011 at 8:23 PM, David Herman <dherman at mozilla.com> wrote:

> And another silent semantic change? I wouldn't be so quick to do that. And
> that's not the direction we were going for __proto__ in the last f2f.
>
> I *wish* __proto__ were just treated as another normal property. And I'd
> like for us to work towards a future where that's the case. I'm just
> skeptical we can do it by cramming it into strict mode.
>
> Dave
>
> On Nov 8, 2011, at 3:50 PM, Mark S. Miller wrote:
>
>
>
> On Tue, Nov 8, 2011 at 3:46 PM, Mark S. Miller <erights at google.com> wrote:
>
>>
>>
>> On Tue, Nov 8, 2011 at 3:33 PM, David Herman <dherman at mozilla.com> wrote:
>>
>>> Perhaps __proto__ should not be writeable in "use strict"?
>>>>
>>>
>>> That's a great idea! This never occurred to me, and I have not heard
>>> anyone suggest this. Thanks!
>>>
>>>
>>> Doesn't work.
>>>
>>>     obj[(function(__){return __ + "proto" + __})("__")]
>>>
>>
>> If the "[" above is a strict "[", it should not be able to address
>> "__proto__", regardless of whether the  "__proto__" is computed or not.
>> Or if we intend only to suppress writing, then
>>
>>      obj[(function(__){return __ + "proto" + __})("__")] = {}
>>
>> should still fail if the "[" above is in strict code.
>>
>
> Sorry, it should not fail. It should simply create a normal property that
> happens to be named "__proto__". Likewise, your first example should simply
> address such a normal property. Then JSON would again be an almost-subset
> of ES5/strict, modulo \u2028 and \u2029.
>
>
>
>>
>>
>>
>>>
>>> Dave
>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111108/ae9d1cb2/attachment-0001.html>


More information about the es-discuss mailing list