-
Notifications
You must be signed in to change notification settings - Fork 136
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
Reverse argument order #4
Comments
Hey @tomhicks-bsf, Thanks for your nice suggestions! The library is implementing a standard and the most expected behavior to put the subject of the operation as the first argument. It's clearly the same way as lodash, underscore and other libraries offer. The idea about partial application and currying is interesting. In many (but not the most) situations it brings useful benefits of reusing the configured functions (like you mention I like the way lodash implemented that: see more details. Rough it may work this way: const v = require('voca/fp');
//
const replaceAll = require('voca/fp/replaceAll');
const changeOsToStars = replaceAll("o", "*"); Such task requires quite a lot of work. But I will think about a plan. |
Voca is in many ways an obvious candidate to auto-curried, data-last, composable-functions. With that said, I (unfortunately) think the current implementation is what seems natural for the majority of javascript developers. Following the lodash way is probably the best way. |
Maybe functions could be FP-altered in
[...]
Same principle with currying. But I'm not sure if this is even an acceptable way, I haven't looked through the source code properly. Question: What would happen to functions with optional parameters? To support auto-currying they would have to be fixed to a specific arity, so would that just mean no optional parameters in the fp functions? |
Hey @Jacse, |
@panzerdp sounds fantastic - good luck 🍀 |
It might be easier to use a more general |
This is quite a big suggestion, but in my opinion the order of the arguments is inconsistent across functions, and generally the wrong way around.
See these for details:
http://functionaltalks.org/2013/05/27/brian-lonsdorf-hey-underscore-youre-doing-it-wrong/
https://jsleao.wordpress.com/2015/02/22/curry-and-compose-why-you-should-be-using-something-like-ramda-in-your-code/
There are some cases where API is the right way around, and would allow for currying or partial application:
Here, you take config first, data last, which is the "right way". This allows you to things like:
which allows you to use this function in compose chains, for example.
You cannot do that with this function:
If the order were reversed, and currying implemented, you could do this:
And now you have a function you can use over and over.
With the use of FP (and in particular partial application and currying) on the rise in JavaScript, I think this library should take a leaf from ramda's book and put config first, data last, and curry by default.
Thoughts?
The text was updated successfully, but these errors were encountered: