Sean Catchpole wrote:
However, this can only be done through a tedious declaration of the
function (all those return functions)
and then the (arg1)(arg2)(...) format isn't the best. So I've been
working on a curry function that will change any function in a curried
one. I'll post it on the newsgroup later once I get the last bug figured
out.
I'll be interested to see it. Svend Tofte has one approach [1] that
works, but is rather clunky for my tastes. It involves altering the
function by adding a call to a curry method in the beginning. Cory
Hudson's [2] is a bit cleaner, passing your function into a curry()
function and getting a curried result. But either leads to one problem:
Javascript is often written with optional parameters. This is a very
useful limited form of function overloading. Currying can be seem as an
even more specialized form of overloading, but the two are really not
compatible.
For instance,
compare(a, b) {
return a.length - b.length;
}
would be amenable to currying, and there are clear-cut uses for a
curried version, but what do you do with
compare(a, b, descending) {
return descending ? b.length - a.length : a.length - b.length;
}
which is called as
compare(a, b);
or as
compare(a, b, true);
and in either case should return an integer? We clearly want to have
compare([1, 2, 3], [1, 2, 3, 4, 5, 6, 7]);
return -4 and not to return
function(descending) {
return descending ? 4 : -4;
}
. But I can't see how to have our cake and eat it too. Or am I missing
something fundamental?
This is not to say that a nice currying function wouldn't be useful, but
it would have to be applied judiciously.
This has strayed rather far from JQuery, though, I'm afraid.
I look forward to seeing your results,
-- Scott
[1] http://www.svendtofte.com/code/curried_javascript/
[2] http://www.coryhudson.com/blog/2007/03/10/javascript-currying-redux/
