-
Notifications
You must be signed in to change notification settings - Fork 159
[mf2 JS api] Why this selectKey design? #439
Description
Let me start by saying that the way selectKey works is quite confusing. After reading the selectKey implementation for Number, I to took me a while for me to figure out how both these examples return x:
.local $n = {1 :number}
.match $n
one {{ a }}
1 {{ x }}
one {{ c }}
* {{}}
.local $n = {1 :number}
.local $m = {2 :number}
.match $n $m
1 3 {{ a }}
one 2 {{ x }}
* * {{}}
Once it clicked that the way it works is by calling .selectKey multiple times, each time removing the value that "won" the previous time if it didn't lead to a success.
This means that, if I need to normalize my value to check if it's in the set (and for number it's trivial, it's just a String(num), but for other types it can be much more complex), then:
- the first time I have to normalize it for the "best way"
- the second time I have to normalize it for the "best way" (to discover it's not in the set anymore) and "second best way"
- the third time I have to normalize it for the "best way" (to discover it's not in the set anymore), "second best way" (to discover it's not in the set anymore), and "third best way"
- ... and so on
Why doesn't .selectKey return an array instead, so that it already returns the various matches in priority order and I don't have to re-compute all the previous steps at every call?
If the reason is "because maybe the first match matches, so computing the second and third one is a waste", could it instead return a generator? yield bestMatch; yield secondBestMatch; ...