Aurora VS Canary Map and Set

Mark S. Miller erights at
Thu Jun 14 03:56:42 PDT 2012

On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi
<andrea.giammarchi at> wrote:
> Hi again,
>    here few inconsistencies I have found with latest version, for Mac, of
> these two dev/channel browsers.
> Map#set(key, value)
>   Aurora: Map#set() returns undefined in any case. After, if value is
> undefined/void 0, Map#has(key) will return true and Map#get(key) will return
> undefined/void 0
>   Canary: Map#set() returns the set value in any case. After, if value is
> undefined/void 0, Map#has(key) will return false. The key will be removed
> indeed so the get(key) will return undefined.
> My Take:
>   returning the value with Map#set may become handier than returning always
> undefined, in a JavaScript like code style.
>   deleting implicitly the key makes no sense at all. Map has so much focus
> on edge cases such NaN and +0 VS -0 but an explicit value as undefined is
> cannot be assigned as desired value BUT it can be used as key ?!?? Implicit
> key removal goes against Map#delete(key) logic too since this method returns
> true or false accordingly if the key was there or not.
> As Summary
> *anything value Map#set(anything key, anything value) looks the most
> concrete/meaningful signature without implicit Map#delete(key) calls ...
> please clarify if what I am saying makes sense and if both Aurora and Canary
> will follow this behavior, thanks.

I'd like to remind everyone that there's a draft spec at
This is likely to change on the way to becoming official. But by this
spec, the behavior you report for Aurora is correct and Canary is
buggy. I'd appreciate it if you would file a bug report. Thanks.

> Set#delete(keyAsValue)
>   Aurora: consistent behavior with Map#delete(key) ... the returned value is
> a boolean, true or false if the key was there
>   Canary: inconsistent behavior with Map#delete(key) ...
> Set#delete(keyAsValue) returns undefined and I really do not understand why
> this is happening. My tests fails with surprise here while these where green
> before ... bad choice, imho, I'd like to understand why is that.

By the draft spec, again Aurora is correct and Canary is buggy.

> Set#add(keyAsValue)
>   both Aurora and Canary returns undefined here and I find this a bit
> inconsistent too. I see Set#add as a simplified Map#set where keyAsValue
> could be returned.

Returning undefined is consistent both with Aurora's behavior for
Map#set and with the draft spec for Map#set.

> If your argument is that Set#add(keyAsValue) has different purpose than
> Map#set I wonder why the behavior is not consistent with Map#delete(key)
> where at least, Set#add(keyAsValue) could return true or false accordingly
> if the keyAsValue was there or not.

This may be a better design -- I can make arguments both ways and we
should have that argument. But that's the way it's currently (draft)
speced, so for the sake of browser agreement, we should follow the
draft spec until we agree on something else.

OTOH, in alphas, betas, canarys, nightlys, or whatever prior to
official release, it's also good to experiment with changes one is
thinking of proposing -- in order to gain experience first. I doubt
that is what is happening here, but if it is, we should not discourage

> if (Set#add(generic)) {
>   // first time generic has been set
> } else {
>   // generic was there already
> }
> My Take:
>   while the returning boolean could be considered superfluous, since it
> could be implemented in Set#delete(generic) or simply passing through the
> Set#has(generic) check, returning the added generic value would be more than
> helpful for many common tasks.
> mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/);
> Thanks for any sort of clarification.
> Best Regards,
>     Andrea Giammarchi
> _______________________________________________
> es-discuss mailing list
> es-discuss at


More information about the es-discuss mailing list