Consistency for Eq a / Ord a functions with suffix "By"
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- api
Hướng nghiên cứu
Read the array API definitions for difference, elem, notElem, elemIndex, and elemLastIndex, then compare their signatures and naming with the existing By variants listed in the issue. Decide whether differenceBy fits the API’s conventions and identify the corresponding functions to address. Done means the API naming and custom equality support are consistent; the issue provides no file or test paths to start from.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
As I look through the API, I see a pretty consistent pattern of "You can rely on a typeclass for Eq/Ord or you can supply your own".
So if a type signature has forall a. Eq a => ..., there's often a version that removes this constraint and adds in a function like forall a. (a -> a -> Boolean) ...
There even seems like a pretty consistent naming pattern:
insert & insertBy
sort & sortBy
group & groupBy
groupAll & groupAllBy
nub & nubBy
nubEq & nubByEq <- Sort of a break from the pattern, but still
union & unionBy
delete & deleteBy
intersect & intersectBy
But it feels sort of arbitrary when some functions don't follow that pattern
For example: difference
I'd expect to see
difference :: forall a. Eq a => Array a -> Array a -> Array a
differenceBy :: forall a. (a -> a -> Boolean) -> Array a -> Array a -> Array a
The same holds for elem, notElem, elemIndex, and elemLastIndex, but these are covered by find >>> isJust, find >>> isNothing, findIndex, and findLastIndex. I understand a departure in naming pattern here since Eq a is replaced with (a -> Boolean) instead of (a -> a -> Boolean).
- Ngôn ngữ chính
- PureScript
- Star
- 58
- Fork
- 70
- Merge trung bình
- 2 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của purescript/purescript-arrays
-
Description text of `difference`Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 55/100
purescript/purescript-arrays#246 ·
-
generate functionĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 35/100
purescript/purescript-arrays#244 · 2 bình luận ·
-
deleteWith function & friendsĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
purescript/purescript-arrays#242 · 2 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
purescript/purescript-arrays#241 ·
-
`groupBy` has unexpected `l` argument for `a -> a -> Boolean` predicateCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 25/100
purescript/purescript-arrays#229 · 3 bình luận ·
Tất cả issue của purescript/purescript-arrays
Issue tương tự
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Mend: dependency security vulnerability
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
ManageIQ/manageiq-pods#1476 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
mcp: typed tool handlers lose wrapped JSON-RPC errorsCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
modelcontextprotocol/go-sdk#1529 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
FinanceFlash/unvibecode#818 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100