Why Ramda source code has more than one curry function, so does Redux compose?
Answer a question
There are _curry1 _curry2 _curry3 _curryN function in Ramda source code
this pattern appears in redux compose function as well
I'm wondering why they use this pattern instead of only use a generic function for all situation?
Does this pattern improve performance ?
Answers
In addition to Kousha's correct answer I'd like to add that the _-prefixed functions are Ramda's internals, not exposed anywhere.
Ramda (disclaimer: I'm one of its founders and primary authors) exposes curryN and a useful gloss on it, curry. The others are used internally only. They carry some additional burdens, especially for helping with the placeholders. But the main thing is that they are not full-fledged Ramda curry functions, only internal helpers that are not ready to be exposed. We could fix them up so that they are, which was the point of that quoted comment, but we never have bothered. There would be some performance benefit, which is probably why Redux does this, but we've not found currying to be a huge performance hit, at least not since we wrote those helpers.
In a stricter library such as Sanctuary, they are the only sort of API that would be allowed, since inputs are not allowed to be variadic. Ramda, though, does a fair bit to support variadic functions. Ramda has chosen not to go down that route.
更多推荐
所有评论(0)