if anyone is also interested I have filed these three bugs: https://code.google.com/p/chromium/issues/detail?id=132741 https://code.google.com/p/chromium/issues/detail?id=132742 https://code.google.com/p/chromium/issues/detail?id=132744
On Thu, Jun 14, 2012 at 2:28 PM, Andrea Giammarchi < [email protected]> wrote: > To summarize, Aurora is correct everywhere while Canary isn't ... and > there's nothing is specs about removing the key if the value is undefined. > > I take Aurora as the right one then, thanks a lot! > > On Thu, Jun 14, 2012 at 12:56 PM, Mark S. Miller <[email protected]>wrote: > >> On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi >> <[email protected]> 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. >> >> >> > >> > >> > Set#delete(keyAsValue) >> > Aurora: consistent behavior with Map#delete(key) ... the returned >> value is >> > a boolean, true or false if the key was there >> > Canary: inconsistent behavior with Map#delete(key) ... >> > Set#delete(keyAsValue) returns undefined and I really do not understand >> why >> > this is happening. My tests fails with surprise here while these where >> green >> > before ... bad choice, imho, I'd like to understand why is that. >> >> By the draft spec, again Aurora is correct and Canary is buggy. >> >> > >> > Set#add(keyAsValue) >> > both Aurora and Canary returns undefined here and I find this a bit >> > inconsistent too. I see Set#add as a simplified Map#set where keyAsValue >> > could be returned. >> >> Returning undefined is consistent both with Aurora's behavior for >> Map#set and with the draft spec for Map#set. >> >> >> > If your argument is that Set#add(keyAsValue) has different purpose than >> > Map#set I wonder why the behavior is not consistent with Map#delete(key) >> > where at least, Set#add(keyAsValue) could return true or false >> accordingly >> > if the keyAsValue was there or not. >> >> This may be a better design -- I can make arguments both ways and we >> should have that argument. But that's the way it's currently (draft) >> speced, so for the sake of browser agreement, we should follow the >> draft spec until we agree on something else. >> >> OTOH, in alphas, betas, canarys, nightlys, or whatever prior to >> official release, it's also good to experiment with changes one is >> thinking of proposing -- in order to gain experience first. I doubt >> that is what is happening here, but if it is, we should not discourage >> it. >> >> >> > >> > if (Set#add(generic)) { >> > // first time generic has been set >> > } else { >> > // generic was there already >> > } >> > >> > My Take: >> > while the returning boolean could be considered superfluous, since it >> > could be implemented in Set#delete(generic) or simply passing through >> the >> > Set#has(generic) check, returning the added generic value would be more >> than >> > helpful for many common tasks. >> > >> > mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/); >> > >> > Thanks for any sort of clarification. >> > >> > Best Regards, >> > Andrea Giammarchi >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> >> >> >> -- >> Cheers, >> --MarkM >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
