Aurora VS Canary Map and Set

David Bruant bruant.d at
Thu Jun 14 05:46:30 PDT 2012

Le 14/06/2012 12:56, Mark S. Miller a écrit :
> 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.
Seeing these inconsistencies for a feature draft spec-ed in relatively 
unambiguous pseudo-ECMAScript code puzzles me.
For relevant features, would it make sense to ship tests alongside with 
the spec?
Implementors do write tests before shipping a feature. Could they agree 
to systematically contribute tests to test262 now that it exists?
I don't think it would be that big of an additional burden but it would 
definitely benefit everyone a lot apparently!


More information about the es-discuss mailing list