[
https://issues.apache.org/jira/browse/GROOVY-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733910#comment-17733910
]
Jochen Theodorou commented on GROOVY-9848:
------------------------------------------
[~paulk]
no sure using "if" helps, because that will also do the Groovy-Truth.
def x = val in map // is boolean
is not equal to
def x = map[val] // x is map.get(\x)
Let me try a different angle. in Javascript and Python the "in" operator looks
for a key of the map/dictionary. That means case 3. I do see alignment in this.
"x in list" checks if list contains x. And if you see a map as a list with a
relation between the elements, then you just have two list to call "in" on.
Thus "x in map" is a replacement for "x in map.keys()". it could be the values
in theory, but you almost always want to handle the keys with a map. For me
that makes sense in Javascript and in Python, so why not have it the same way
in Groovy.
Of course none of Javascript and Python offer switch-case with maps as cases
like we do really. coming back to your example of a switch case. Trying to
translate that to something with case 3 is going to get very ugly. If somebody
is using that, then going for case 3 will cause them to have to rework their
code quite a bit imho... probably the most easy would be really an
if-else-cascade then. Usually
{code:Java}
if (v == b1) {...}
else if (v == b2) {..}
else if (v == b3) {...}
else {...}
{code}
is seen as equal to
{code:Java}
switch(v) {
case b1: ...; break
case b2: ...; break
case b3: ...; break
default:....
}
{code}
But if we wanted that for Groovy we would have used "==". So me personally I am
fine with changing to case 3.
> Allow membership operator to work on maps
> -----------------------------------------
>
> Key: GROOVY-9848
> URL: https://issues.apache.org/jira/browse/GROOVY-9848
> Project: Groovy
> Issue Type: Improvement
> Reporter: Keegan Witt
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
