Improve consistency with other libraries
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 15/100
- Issue 類型
- 重構
- 描述清晰度
- 需要釐清
- 活躍度
- 停滯
研究方向
Start by reading the discussion in this issue and the linked issues #183, purescript-lists#178, and purescript-arrays#192 to understand the existing API drift. Then compare the List, Array, and Set APIs and the linked article’s arguments about type classes. The issue does not settle on a strategy, so a useful outcome would first require a decision about common interfaces and instance placement.
由索引模型根據 Issue 內容生成。
描述
There's a lot in common among containers such as List, Array, Set, but their APIs drift out of sync. What's a good strategy to keep everything up to date?
We could continue to apply techniques such as #183 across these libraries, but that requires constant manual intervention.
Would it be appropriate to use more type classes to enforce common interfaces? Or should we avoid those, as suggested in https://harry.garrood.me/blog/down-with-show-part-1/ ? I still don't have a good understanding of how using more typeclasses leads to trouble.
For example we could have a SetLike type class that provides intersection, union, difference, etc. that List, Array, Set would all have an instance of. A similar strategy could have also helped us avoid https://github.com/purescript/purescript-lists/issues/178 and needing to remember to address https://github.com/purescript/purescript-arrays/issues/192. Interfaces could also cut down on the burden of maintaining duplicated documentation for all of these duplicated functions.
Another minor bit of messiness is that we currently have both intersect and intersection, depending on the container. Of course this can be fixed without resorting to typeclasses, but could also have been prevented by embracing more typeclasses.
Also, what determines whether a typeclass instance is defined in the type or the class? It seems somewhat arbitrary. For example:
Semigroupdefines the instances forArrayandVoidVoiddefines the instance forShowShowdefines the instance forArray
Things would be a bit more organized if the policy in core was to always define instances in the type, which would look like the following:
Voiddefines the instance forShowandSemigroupArraydefines instances forShowandSemigroup
- 主要語言
- PureScript
- 星號
- 61
- 分支
- 50
- 平均合併
- 2 天 6 小時
- 30 天內合併 PR
- 1
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
purescript/purescript-lists 的其他 Issue
-
ZipList is Bind未關閉
難度 4/5 3-5 天 新手友好度 35/100
purescript/purescript-lists#219 · 1 則留言 · 1 個 reaction ·
-
難度 2/5 1-3 小時 新手友好度 48/100
purescript/purescript-lists#218 ·
-
Data.List.NonEmpty.intersect and Data.List.NonEmpty.intersectBy throw when intersection empty可能已有人在做 @evaogbe 於 1066 天前認領。 未關閉good first issue type: bug
難度 4/5 3-5 天 新手友好度 1/100
purescript/purescript-lists#216 · 2 則留言 ·
-
type: enhancement
難度 4/5 3-5 天 新手友好度 25/100
purescript/purescript-lists#197 · 1 則留言 ·
-
type: enhancement
難度 5/5 一週以上 新手友好度 24/100
purescript/purescript-lists#194 · 5 則留言 ·
查看 purescript/purescript-lists 的全部 Issue
相似的 Issue
-
1.3 bug
難度 2/5 1-3 小時 新手友好度 78/100
-
normalizePropName strips `#` characters from Figma property names instead of only the `#id` suffix未關閉
難度 2/5 1-3 小時 新手友好度 72/100
figma/code-connect#419 ·
-
bug
難度 2/5 1-3 小時 新手友好度 70/100
jeanibarz/knowledge-base-mcp-server#1268 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 78/100
nicobailon/pi-subagents#3276 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆