Expose a length property for curried functions

[JamieDixon]

While working through a first-pass on what Async.fromNode might look like with its incoming parameter curried (see #478), I noticed that I was unable to check for a length on incoming curried functions.

With this change in place the code for allowing curried functions with Async.fromNode passes the tests.

What do you think about this change to curry where we expose the length on curried of the original fn that was passed in?

[coveralls]

Coverage remained the same at 100.0% when pulling 0b7c7d7 on JamieDixon:curried-expose-length into ce8f939 on evilsoft:master.

[evilsoft]

Just got one question on the use of configurable, but other than that a welcome addition.

[evilsoft]

Why allow this to be configurable?
I would think that this will always be Number and should never be able to be deleted.

[JamieDixon]

This is a good question and I wish I had a good answer in response.

I literally took inspiration from the following in DevTools:

Object.getOwnPropertyDescriptors(() => {}).length

I'm more than happy to remove this or set it to false.

[evilsoft]

I would say, remove it for now. I cannot see a need for it to be configurable.
It defaults to false so no need to explicitly set it (unless you want to communicate that this property is in debate?)

[JamieDixon]

Excellent! I've remove the property. Thanks for bringing this one up because I wasn't entirely sure whether it should be included or not 👍

[evilsoft]

What do you think about this change to curry where we expose the length on curried of the original fn that was passed in?

This will only be for the "last" fn passed in yeah? For instance this would report as (1), even though it is really (2)

// fn :: String -> Array -> Array
const fn = curry(
  compose(map, objOf)
)

[JamieDixon]

@evilsoft Hmmm, that's an interesting one. The length of a function with implicit parameters (arguments or ...args) would be 0 I believe?

If my thinking is on track, the arity of the fn returned by compose is 0 because it's essentially infinite?

[JamieDixon]

There would be a similar discrepancy with functions that employ default values, since the length property only indicates parameters up to the first with a default value.

This number excludes the rest parameter and only includes parameters before the first one with a default value.

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/length

That is to say, I believe this implementation is consistent with expectations as per the spec. What do you think?

[JamieDixon]

In addition to this, I wonder whether we could fix the arity of composed functions to the arity of the right-most function in the composition? Just a thought.

[evilsoft]

In addition to this, I wonder whether we could fix the arity of composed functions to the arity of the right-most function in the composition? Just a thought.

So this will open up a can of worms, especially if we use this for determining argument application. Because we currently allow an n-ary interface (uncurried) of the right-most function that above function will not be applied properly. When curried, if it reports a length of (2) it will apply it to objOf, passing an Object to map.

We are currently debating limiting arguments to compose/pipe functions to unary for a number of reasons including this behavior. Also it makes functions easier to reason about when composing.

[evilsoft]

If my thinking is on track, the arity of the fn returned by compose is 0 because it's essentially infinite?

Yep totes! Good call!

[evilsoft]

That is to say, I believe this implementation is consistent with expectations as per the spec. What do you think?

It is 💯, I am just saying that when using this property, we should be aware that this does not pertain to the overall function as a whole, just the current "frame" of the curry stack. So if we are gathering and applying arguments before running a side-effect or something, we cannot use this length as the sole indication that we now have all of our arguments and are ready to apply them.

[JamieDixon]

That is to say, I believe this implementation is consistent with expectations as per the spec. What do you think?

It is 💯, I am just saying that when using this property, we should be aware that this does not pertain to the overall function as a whole, just the current "frame" of the curry stack. So if we are gathering and applying arguments before running a side-effect or something, we cannot use this length as the sole indication that we now have all of our arguments and are ready to apply them.

Oh yes! Absolutely.

[evilsoft]

Unless @dalefrancis88 says 👻 to anything I would say this GTG!

[dalefrancis88]

I think this is fine to add, this only adds value. I know that this has popped up a few times.

I think @evilsoft has covered some really great concerns and they've been addressed, i'm curious to see what will come from this being added.