Aurora VS Canary Map and Set
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 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.
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!
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 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!
if anyone is also interested I have filed these three bugs: code.google.com/p/chromium/issues/detail?id=132741, code.google.com/p/chromium/issues/detail?id=132742, code.google.com/p/chromium/issues/detail?id=132744
I have written tests already so if I have to change few things and push to test262 just let me know, thanks.
br
Mark S. Miller wrote:
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.
We should discuss first, though. The way to proceed is not for a browser vendor (especially one with market power to abuse, not saying this is any particular vendor! shifts over time) try stuff out that no peer has ever heard proposed in the strawman section of the wiki, even in an open issues or two-competing-straw-designs setting.
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.
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.
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. 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.
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 , Andrea Giammarchi
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. 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. 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. 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120614/23128881/attachment.html>