-
Notifications
You must be signed in to change notification settings - Fork 30
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
Automatic currying #20
Comments
I can say that it's worked well for Ramda, which made the decision to do so from the beginning. In fact, having a library that incorporated easily composable curried functions was really the main goal of Ramda. It looks as though all the functions in fn.js already have their parameters ordered well for currying, so it should be straightforward to do. A word of warning, though. When Ramda started to get some attention, it became immediately clear that Ramda's curry implementation needed work for performance reasons. We got through that, but it wasn't a fun two weeks. I'd be very excited to see fn.js do this also. |
Totally agree that this should be done. I was surprised this wasn't the case. Is there any downside to it? |
The only downsides I see is that functions are heavier. |
I think this should be added. initially without too much consideration to performance. Work toward setting the correct ordering of parameters etc. Then optimise the functions once we have a way of creating performance metrics |
operations that act on collections should take either 2 arguments or 1 argument that is a collection. |
After using fn.js for a bit now, I'm starting to wonder if I regret not making most methods auto-currying. I'm considering making this change for 1.0 and would welcome comments for or against based on your experience.
The text was updated successfully, but these errors were encountered: