_.unzip unit tests not testing documented usage.

[jdalton]

The _.unzip unit tests are testing only

_.unzip(array1, array2, array3);

which is not the documented usage.

[jdalton]

Looks like it's documented in the source one way and in the documentation another:

  // The inverse operation to `_.zip`. If given an array of pairs it
  // returns an array of the paired elements split into two left and
  // right element arrays, if given an array of triples it returns a
  // three element array and so on. For example, `_.unzip` given
  // `[['a',1],['b',2],['c',3]]` returns the array
  // [['a','b','c'],[1,2,3]].

[jdalton]

The operation:

 _.unzip(_.zip(['moe', 'larry'], [30, 40], [true, false]));
// produces [[["moe",30,true]],[["larry",40,false]]]
// instead of [['moe', 'larry'], [30, 40], [true, false]]

[jdalton]

Looks like this change was introduced in the actual 1.5.0 commit :/

[jashkenas]

Not broke, changed. Updated the comment above.

[jdalton]

Why the last minute change in functionality?
Now it can't be easily used to unzip a zipped value w/o using apply or referencing each element of the zipped result.
Can you explain what the benefit is? (since it's not what was originally requested, discussed, or implemented)

[knowtheory]

It's a bit of a bummer that zip and unzip aren't inverse functions. I wish there were some equivalent of Ruby's splat operator to deal with having to do something like this:

res = _.zip(['moe', 'larry'], [30, 40], [true, false]);
_.unzip(res[0], res[1]);

Though, none of the other array functions take multiple arguments and return an array of results, on the other hand.

[jashkenas]

Because this way, they're parallel. Previously, zip took individual arrays as arguments, and unzip took an array of (somewhat carefully constructed) arrays. Previously, they weren't inverse functions, because you couldn't have passed the output of unzip directly into zip.

This way, they both allow input as individual arguments (as you might want to write it), and can be apply'd in the same way to take in an array of arrays as a singular argument as well.

[jdalton]

Wait, now _.zip is an alias for _.unzip:

_.zip(['moe', 'larry', 'curly'], [30, 40, 50], [true, false, false]);
// => [["moe", 30, true], ["larry", 40, false], ["curly", 50, false]]

_.unzip(['moe', 'larry', 'curly'], [30, 40, 50], [true, false, false]);
// => [["moe", 30, true], ["larry", 40, false], ["curly", 50, false]]

The docs for _.unzip (minus sentence with opposite) are interchangeable with _.zip, which means the _.unzip docs are misleading as it states it's the opposite of _.zip and the code is extraneous as it's nothing more than _.zip.

I think it would have made more sense to keep it the way it was originally implemented, possibly extending _.zip to accept _.unzip results.

[jashkenas]

Quite so. I guess that the original proposal to add unzip was a bit foolish from the get-go. Ruby, for example, only has a zip, and Python, for another, only implements a zip as well -- for precisely this reason. An index-based-transposition is a transposition, and can be used to go back and forth.

[ghost]

Cool. I'm going to go with making _.unzip an alias of _.zip and allow it to consume its results.

var expected = [['moe', 'larry'], [30, 40]];
 _.unzip(_.zip(_.unzip(_.zip(expected))));
// => [['moe', 'larry'], [30, 40]]