Use cases for WeakMap

Mark S. Miller erights at google.com
Sat May 14 16:22:37 PDT 2011


On Sat, May 14, 2011 at 4:01 PM, Oliver Hunt <oliver at apple.com> wrote:

> No, I am wrong, if i have a key that i can ever reuse, the map is strong,
> because the key will keep the value live.  These aren't weak maps, they are
> strong maps that don't leak keys that have become dead.
>
> I can kind of see the value of this kind of structure, but I don't believe
> it is a WeakMap.
>

Does the following summary agree with your point?  "A WeakMap is just a
non-enumerable object identity keyed map, whose API is designed to allow
implementations to transparently collect more unreachable collections.
Non-normatively, implementation are expected to exploit this opportunity.".

Note that I did not say "weak" in this summary. The original proposed name
was EphemeronTable, which everyone hated, including myself. But we gave it
this name to distinguish it from the traditional weak-key hashtable,
implemented from weak references and notification, since weak-key hashtables
cannot be as non-leaky as ephemeron tables.

When someone -- wasn't it you? -- suggested "WeakMap", IIRC we all
immediately fell in love with the name. Speaking only for myself, I like
"WeakMap" because it suggests some connection with weak references without
being specific, and clearly being distinguished from weak-key hashtable. As
a new coinage, we're free to define precisely what it means, as we have.

As for genuine weak references, which enable a range of use cases that
WeakMaps do not, what do you think of <
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references>? I hope to
propose something along these lines for ES-after-next.


>
> --Oliver
>
> On May 14, 2011, at 3:48 PM, Oliver Hunt wrote:
>
> > Don't mind me, I misread the spec (again) as saying that if either the
> key or value was live then the entire mapping remained alive.
> >
> > --Oliver
> >
> > On May 14, 2011, at 3:37 PM, Oliver Hunt wrote:
> >
> >> It's not that they're impossible, it's that they all reduce to a strong
> map with automatic deletion, rather than "WeakMap".
> >>
> >> Take any form of weak cache, say for example you want to cache the
> object representation that's the result of an XHR (or some such)
> >>
> >> eg.  you want to do
> >>
> >> function getObject(url) {
> >>   var result = myCache.get(url);
> >>   if (result)
> >>      return result;
> >>   result =
> Object.freeze(JSON.parse(loadURLWithSynchXHR(url).responseText));
> >>   myCache.set(url, result);
> >>   return result;
> >> }
> >>
> >> Except you this doesn't work, because the map needs to have an object
> key, so the string is not allowed, we have to do new String(url) or some
> such as the key, so for a use case like this we need a map from string
> primitive to String object, so making the map a strong map.
> >>
> >> Can you provide a use case where you have an object key as the usual
> programming idiom?
> >>
> >> --Oliver
> >>
> >> On May 14, 2011, at 3:25 PM, Andreas Gal wrote:
> >>
> >>>
> >>> Can you describe those common use cases, and how they are impossible
> with the current specification?
> >>>
> >>> Andreas
> >>>
> >>> On May 14, 2011, at 3:05 PM, Oliver Hunt wrote:
> >>>
> >>>> The more I read the WeakMap spec, the more it seems to prevent the
> common use cases I know of.  Could someone give a few examples of problems
> the current weakmap spec solves?
> >>>>
> >>>> --Oliver
> >>>>
> >>>> _______________________________________________
> >>>> es-discuss mailing list
> >>>> es-discuss at mozilla.org
> >>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> 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/20110514/a96e674e/attachment.html>


More information about the es-discuss mailing list