{Weak|}{Map|Set}

[Mark S. Miller]

On Thu, Sep 15, 2011 at 8:41 AM, Sean Eagan <seaneagan1 at gmail.com> wrote:

> Why constrain WeakMap to object keys, but not Map and Set ?  I think
> it is because "Weak" only makes sense for object keys.  However, if we
> base the distinction on iterability rather than weakness as David
> suggested, then we do not have to include an object key constraint
> anywhere.


Hi Sean, that is a perfect example of how quickly we could go from
de-emphasizing the purpose to losing the purpose. With this restriction
relaxed, I can well imagine programmers using large numbers or strings as
keys, thinking the corresponding association would be collected when those
numbers or strings no longer otherwise exist in their program. Programmers
coming from languages where boxed large numbers or strings have an
observable unique identity will be especially prone to fall into this trap.

The result is that their program has a memory leak that remains silent until
they stress their program enough to run out of memory. At which point, they
may have great difficultly tracking down the cause -- especially if this
misuse of *Map is buried in some library written by someone else. Given the
normal invisibility of the symptom, this is quite likely. Better to error
early with a clear diagnostic, so no one is confused about what keys can be
usefully used.

Which btw, does bring up one way in which the FF implementation of WeakMaps
is too strict. By the above reasoning, we should reject non-objects in the
key position of a .set(). We need not reject it in the key position of a
.get(), .has(), or .delete(). All all cases, we know that a non-object key
cannot correspond to any stored association, so .get(), .has(), and
.delete() can respond as if for any other not-found key.



>  We could have:
>
> Map - current WeakMap minus object key constraint
> IterableMap - current Map
> Set - a "WeakSet" (David's above use case) minus object key constraint
> IterableSet - current Set
>
> This would also encourage use of the non-leaky abstractions where
> iterability is not a requirement.
>
> Also, what are the iteration order semantics ?  Consider the following:
>
> let s = new Set // i.e. IterableSet
> s.add(0);
> s.add(1);
> // clearly [0,1] here
> s.add(0);
> // [1, 0] now ?
> s.delete(0);
> s.add(0);
> // clearly [1, 0] here
>
> let m = new Map; // i.e. IterableMap
> m.set(0, 2);
> m.set(1, 2);
> // clearly [0,1] here
> m.set(0, 2); // set to existing value
> // [1, 0] now ?
> m.set(0, 3); // actually change value
> // [1, 0] now ?
> m.delete(0);
> m.set(0, 2);
> // clearly [1, 0] here
>
> Also, for the iteration API of Map (i.e. IterableMap) and Set (i.e.
> IterableSet), why not integrate with iterators [1] :
>
> let m = new Map, s = new Set;
> ...
> for(i of m.iterator()) {
>  ...
> }
> for(i of s.iterator()) {
>  ...
> }
>
> [1] http://wiki.ecmascript.org/doku.php?id=harmony:iterators
>
> On Thu, Sep 15, 2011 at 2:10 AM, Brendan Eich <brendan at mozilla.com> wrote:
> > On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote:
> >
> >> I would prefer ObjectMap (the keys are restricted to objects).
> >
> > Now that you point it out (again), I agree.
> >
> > People who know a bit about GC also confuse WeakMap with WeakRef/WeakPtr,
> which we have only in the strawman space:
> >
> > http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
> >
> > /be
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> Thanks,
> Sean Eagan
>



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