I have written tests already so if I have to change few things and push to test262 just let me know, thanks.
br On Thu, Jun 14, 2012 at 2:46 PM, David Bruant <bruan...@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.giammar...@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<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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
