Feature/slice abstractions #27
Conversation
| func (slice Slice[T]) Filter(predicate Predicate[T]) Slice[T] { | ||
| filtered := Slice[T]{} | ||
| for _, v := range slice { | ||
| if predicate == nil || predicate(v) { | ||
| filtered = append(filtered, v) | ||
| } | ||
| } | ||
| return filtered | ||
| } |
There was a problem hiding this comment.
| func (slice Slice[T]) Filter(predicate Predicate[T]) Slice[T] { | |
| filtered := Slice[T]{} | |
| for _, v := range slice { | |
| if predicate == nil || predicate(v) { | |
| filtered = append(filtered, v) | |
| } | |
| } | |
| return filtered | |
| } | |
| func Filter(slice Slice[T], predicate Predicate[T]) Slice[T] { | |
| filtered := Slice[T]{} | |
| for _, v := range slice { | |
| if predicate == nil || predicate(v) { | |
| filtered = append(filtered, v) | |
| } | |
| } | |
| return filtered | |
| } |
i think this type of params maybe better for utilization in code
There was a problem hiding this comment.
Can you be more specific on the reasons why? I aggree that this could have less friction with legacy code, but at this point we should question what is indeed idiomatic in Golang. It seems quite reasonable that generic type abstractions like Slice[T] or Map[TK,TV] would be a better choice for 1.18+ Golang code, as custom, reusable behaviour can be easily added to satistfy application needs.
There was a problem hiding this comment.
i think is better have less friction with legacy code, cuz the community probably will make something similar to this PR in the std lib, so we can make an agnostic function that we recive any slice is better for now
What this PR does?
Creating slice abstractions using Go generics feature.
- Before
No slice abstractions.
- After
An initial version of slice abstractions.
- How to test it?
make test