Aurora VS Canary Map and Set

[Andrea Giammarchi]

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 <
andrea.giammarchi at gmail.com> 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 <erights at google.com>wrote:
>
>> 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.
>>
>>
>> >
>> >
>> > 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
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120614/f2889aaf/attachment-0001.html>