为什么 Ramda 源码有不止一个 curry 函数,Redux compose 也有?

Why Ramda source code has more than one curry function, so does Redux compose?

Ramda source code

中有_curry1_curry2_curry3_curryN函数

这种模式也出现在 redux compose function

我想知道为什么他们使用这种模式而不是只对所有情况使用通用函数?

此模式是否提高了性能?

这是一个很好的问题,谷歌搜索我发现了这个issue. To quote CrossEye's comment

We could consider exposing curry2 and curry3 directly. The biggest problem would be in documentation. How would we comfortably explain well the tradeoffs between curry, which is less efficient, but retains context and passes through all arguments supplied, and curry2/curry3, which can run more quickly, but which lose their calling context and ignore extra arguments supplied. But I see no real issues with actually having these functions exposed.

看起来 _curry1_curry2_curry3 不能完全替换为 _curryN

除了 Kousha 的正确答案之外,我想补充一点,_ 前缀函数是 Ramda 的内部,没有暴露在任何地方。

Ramda(免责声明:我是它的创始人和主要作者之一)公开了 curryN 并对其进行了有用的解释,curry。其他仅在内部使用。他们承担了一些额外的负担,尤其是在帮助占位符方面。但最主要的是,它们并不是成熟的 Ramda curry 函数,只是尚未准备好暴露的内部助手。我们可以修复它们,使它们成为原样,这是引用的评论的重点,但我们从来没有费心过。会有一些性能上的好处,这可能就是 Redux 这样做的原因,但我们没有发现柯里化对性能造成巨大的影响,至少自从我们编写了这些助手以来没有。

在像 Sanctuary 这样更严格的库中,它们是唯一允许的 API 类型,因为输入不允许是可变的。不过,Ramda 在支持可变函数方面做得相当不错。 Ramda 选择不走那条路。