[mf2 JS api] Why this `selectKey` design?
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 30/100
- Issue 類型
- 功能
- 描述清晰度
- 需要釐清
- 活躍度
- 停滯
- 技術堆疊
- javascript, typescript
- 領域
- api
研究方向
Start with the selectKey implementation for Number and trace how repeated calls produce the priority-ordered matches in the MF2 examples. Compare the proposed array and generator alternatives, then define the API behavior and completion criteria before making a change.
由索引模型根據 Issue 內容生成。
描述
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; ...
- 主要語言
- TypeScript
- 星號
- 1.8k
- 分支
- 161
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
messageformat/messageformat 的其他 Issue
-
help wanted
難度 3/5 1-2 天 新手友好度 35/100
messageformat/messageformat#462 · 4 則留言 ·
-
難度 3/5 1-2 天 新手友好度 45/100
messageformat/messageformat#455 · 1 則留言 ·
-
難度 2/5 1-3 小時 新手友好度 45/100
messageformat/messageformat#434 ·
-
難度 5/5 一週以上 新手友好度 30/100
messageformat/messageformat#406 · 1 則留言 ·
-
難度 5/5 一週以上 新手友好度 25/100
messageformat/messageformat#405 · 7 則留言 · 9 個 reaction ·
查看 messageformat/messageformat 的全部 Issue
相似的 Issue
-
bug
難度 1/5 1 小時以內 新手友好度 88/100
StabilityNexus/Fate-EVM-Frontend#153 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
code-yeongyu/oh-my-openagent#9039 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 84/100
Tencent/teamai-cli#862 ·
維護者通常 1 天內回覆
-
bug good first issue hacktoberfest redis
難度 2/5 1-3 小時 新手友好度 88/100
libredb/libredb-studio#1164 ·
維護者通常 1 天內回覆
-
flake
難度 2/5 1-3 小時 新手友好度 85/100
維護者通常 1 天內回覆