Aurora VS Canary Map and Set
David Bruant
bruant.d at gmail.com
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 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 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
> <http://wiki.ecmascript.org/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
More information about the es-discuss
mailing list