Skip to content

[mf2 JS api] Why this selectKey design? #439

@nicolo-ribaudo

Description

@nicolo-ribaudo

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; ...

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions