Aurora VS Canary Map and Set
andrea.giammarchi at gmail.com
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 gmail.com> 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 gmail.com> 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
>>> 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
>>> deleting implicitly the key makes no sense at all. Map has so much
>>> 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 ?!??
>>> key removal goes against Map#delete(key) logic too since this method
>>> 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
>>> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss