A different semantics for WeakMap#get default value

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Jan 16 13:05:23 PST 2012


I would also say that if you can carry both the keyObject and its
defaultValue with you all the time you may not need at all to store it as
weak map ... looks to me you are missing the point where the relation
should be created, using the get() as generic action/entry point to do that.

I believe relate a keyObject with undefined does not simply make sense in
any daily basis logic I can think of so a function or a method as extension
of the WeakMap.prototype would solve everything with similar signature
suggested by Axel, isn't it?

br

On Mon, Jan 16, 2012 at 9:56 PM, Mark S. Miller <erights at google.com> wrote:

> I like the idea of the two argument get as proposed by David. (In fact, I
> like it so much that I thought I'd already specified it that way ;).)
> David, I'm glad to see you got it right in your suggestion at <
> http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#alternate_spec_based_on_ff6.0a1
> >.
>
> Axel, I do not like your elaboration because it turns a query operation
> into a possibly occasionally side-effecting operation. As it is now, I can
> give someone a read-only view of a WeakMap wm my simply giving them
>
>     { get: wm.get.bind(wm), has: wm.has.bind(wm) }
>
>
> On Mon, Jan 16, 2012 at 12:26 PM, Axel Rauschmayer <axel at rauschma.de>wrote:
>
>> One probably should separate two concerns: providing a default value vs.
>> adding missing values to the collection.
>>
>> One possible signature:
>>
>>      function get(key, default = undefined, addIfMissing = false)
>>
>> The above would also allow you to store `undefined` and detect missing
>> values, by using a special value (e.g. named NO_VALUE) as the default.
>>
>> On Jan 16, 2012, at 21:09 , David Bruant wrote:
>>
>> Hi,
>>
>> I recently wrote some code using WeakMaps and the following pattern
>> keeps coming over and over:
>> -----
>> var v = wm.get(o);
>> if(v === undefined){
>>    v = someValue;
>>    order.set(o, v);
>> }
>>
>> // now, wn has a value for o (either it already did or it's been added)
>> // v === wm.get(o)
>> // play with v
>> -----
>>
>> The "v === undefined" is fine in my case, because I know I never store
>> "undefined" as a value.
>>
>> I thought that maybe the semantics of WeakMap#get could be changed
>> whenever the key is not used to set the value and return it.
>> My pattern would be reduced to:
>> -----
>> var v = wm.get(o, someValue);
>> // now, wn has a value for o (either it already did or it's been added)
>> // v === wm.get(o)
>> // play with v
>> -----
>>
>> Thinking more about the current semantics, I thought that what is
>> currently done could be achieved a bit differently:
>> -----
>> var v = wm.get(o, def);
>> // almost equivalent to:
>> var v = wm.get(o) || def;
>> -----
>> There is a difference when the vaue stored in the weak map is a falsy
>> value.
>>
>> My personal experience is to store mostly objects (so truthy) as weak
>> map values, so I wouldn't be affected. Has anyone else experience in
>> storing falsy values?
>>
>> David
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>         --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120116/5be0a861/attachment.html>


More information about the es-discuss mailing list