Re: WindowProxy as the key in ES6 Set/Map/WeakSet/WeakMap

On Wed, Apr 16, 2014 at 8:35 AM, Rick Waldron <waldron.rick@gmail.com>wrote:

> On Wed, Apr 16, 2014 at 10:23 AM, Adam Barth <abarth@chromium.org> wrote:
>
>> On Wed, Apr 16, 2014 at 7:13 AM, Adam Barth <abarth@chromium.org> wrote:
>>
>>> On Wed, Apr 16, 2014 at 6:57 AM, Domenic Denicola <
>>> domenic@domenicdenicola.com> wrote:
>>>
>>>> Let’s put it this way; perhaps what Mark’s saying will be clearer.
>>>>
>>>> Given:
>>>>
>>>> ```js
>>>> const m = new Map();
>>>> m.set(windowProxyInstance, "foo");
>>>> ```
>>>>
>>>> (and given that nothing else is added to `m`), then `m.get(x) ===
>>>> "foo"` should be true _if and only if_ SameValueZero(x,
>>>> windowProxyInstance) is true (which in this case reduces to `x ===
>>>> windowProxyInstance`).
>>>>
>>>> Window proxies should do nothing to violate this invariant of `Map`s.
>>>>
>>>> With that in mind, is there something special about window proxies that
>>>> would allow them to abide by this invariant but still run into the
>>>> questions and problems stated in this thread?
>>>>
>>>
>>> Presumably you would agree that if I wrote:
>>>
>>> windowProxyInstance = someOtherObject;
>>>
>>> then operator=== questions about windowProxyInstance wouldn't be
>>> relevant for answering questions about how m.get behaves.
>>>
>>> One way of phrasing the original question is asking whether navigating a
>>> browsing context keeps the identity of the windowProxyInstance constant or
>>> whether the identity of the windowProxyInstance changes and all fields
>>> containing a reference to the previous windowProxyInstance are updated to
>>> refer to the new windowProxyInstance.
>>>
>>> I don't believe there's an experiment you can run today in browsers to
>>> answer that question.  Map would give you a way to answer that question,
>>> which is why we need to decide what the answer ought to be.
>>>
>>
>> It might be interesting to think about how private names interact with
>> WindowProxy.
>>
>> var tools = (function () {
>>   private unique;
>>   function store(x) { x.unique = 42; }
>>   function check(x) { return x.unique === 42; }
>>   return { store: store, check: check };
>> })();
>>
>
> Is this a hypothetical language feature? There are no private names and no
> private keyword in ES6.
>


Oh, sorry.  I'm not sure what stage the various proposals are in.  I
grabbed the syntax from
http://wiki.ecmascript.org/doku.php?id=strawman:private_names

If private names are still viewed as futuristic, we can worry about
resolving these inconsistencies when they come over the horizon.

Adam