hey guys, do you have any ideas how can I solve this much more elegant? thanks,Tamas
input is
['apple', 'the', 'one', 'two', 'three', 'elephant', 'whatever']
var filterByLength = R.filter(function(str) {
return str.length > 3 && str.length < 6;
});
desired output is
['apple', 'three']
that's obviously longer, though
It's because
R.lt(x, y) means x < y and curried arguments apply left to right. https://github.com/algesten/fnuc exists mainly because that's Kind of Weird.
Since those functions are all binary it shouldn't be too difficult to figure out how the reverse-curry should behave, I figure.
Oh hey, speaking of: Why's the placeholder an object with a specially-named field on it? Just making it an empty object and then comparing against that in the functions would work too, no?
It's pretty easy to make a universal claim that
fn(a, b) === fn(a)(b) for Ramda functions. To say its the same except for certain non-commutative operators was problematic. And we probably couldn't just say binary functions, either, or would you expect R.map(fn, list) but R.map(list)(fn) ? Madness.
@Avaq where does Ramda swap arguments?
Or are you suggesting that we should?
@CrossEye Yeah, I mean reversed, as opposed to say, underscore. The data comes last. When I'm unsure about which of the arguments goes for "data", I use the "assign partially applied function to variable and ask myself what I would expect it to do"-method. Though that method seems to fail for Ramda's
gt and lt, like I explained. It's not the end of the world, but Ramda's argument order has started to make a lot of sense to me, until I met gt and lt just now. :P
Compare 0.15: http://bit.ly/1PUEiW6 to current:http://bit.ly/1PUEiWa on
R.pipe(R.add, R.map)(10)([1, 2, 3])
Yes, for a while we had flipped versions of some of these functions. We lost them when we thought it was all figured out with the operators idea. The whole thing was started by my looking for good names for flipped versions of
lt, gte, etc. We had subtractN, divideBy, and such, but no good names for these.
I'd love a better solution, but
R.lt(7, 12) just seems to me it should return true and divide(20, 5) should return 4 not 0.25. fnuc was built around trying to solve this issue, but I think it ends up somewhat incoherent.
Obviously it'd still return a function taking the second parameter, but the point is it's only allowed to take one argument at a time. Like a Real Haskell Function.
It's an odd one to think about, but my intuition went with
R.lt(6) to test if the following value is less than 6. I think I've even used it like that to explain currying to colleagues. :P
Haha, so when you call
R(x), all of Ramda's functions are partially applied with x, and the results are returned in an object. That's an interesting way of doing things. :P
@Avaq, @00Davo: One thing that bothers me about the chaining syntaxes is that they usually only apply to the libraries built-in functions. In
R.compose/R.pipe, there's nothing special about Ramda functions; you can pass anything you want. So, while you could do something like `R(3).someRfunc, the only way I know to make it more generic so that you could apply any other function you like is with a stateful registration process.
So yes, I've thought about this idea a bit! :smile: Although I never considered using
R itself as the function.
@TheLudd: We'll see what happens. It's not at all clear that people will want to roll back the
compose changes.