Aurora VS Canary Map and Set

Andrea Giammarchi andrea.giammarchi at
Thu Jun 14 05:51:47 PDT 2012

I have written tests already so if I have to change few things and push to
test262 just let me know, thanks.


On Thu, Jun 14, 2012 at 2:46 PM, David Bruant <bruant.d at> wrote:

> 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
>> <**doku.php?id=harmony:simple_**maps_and_sets<>
>> >.
>> 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!
> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list