-
-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predicate factory #217
Labels
enhancement
New feature or request
Comments
Just came here to open the same issue. Besides, this way we'll get rid of a ton of runtime allocations (every callback, every array — they are all objects created at runtime and bloat GC). |
I wrote a small representation of how it might be build: |
FYI Effect has a "lazy" matcher https://effect.website/docs/code-style/pattern-matching |
Lovely, tyank you! Is it possible to use one matcher inside another? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
the
match
function is the way to start defining cases for a value, but its design is limited because its reactive rather than proactive, by this i mean that you can only define cases when the value exists in the scope but there's no way to define case handling logic in a deferred and composable wayDescribe the solution you'd like
I think this can be solved if there were an API that allowed for the definition of cases without having the value that will be matched against them, for example
Now we have a lazy definition of pattern matching, that can be run against any number of values in a pure way and it could also be made composable
Describe alternatives you've considered
the naive way of course would be to make heavy use of lambdas but it would be quite ugly for composability
The text was updated successfully, but these errors were encountered: