Allow caller to specify value for padding shorter of Zip sequences

[atifaziz]

I think it would be good to allow the caller to control what is being used to pad the shorter collection if desired, rather than relying on default(TResult). Especially for numerics, where 0 may very well have a meaning for the caller, other than "not there".

Since this would change the method signature, new method overrides would probably be required. These methods would probably have no need for a zip strategy argument either.

Here is the method signature I would envision:

private static IEnumerable<TResult> ZipImpl<TFirst, TSecond, TResult>(
    IEnumerable<TFirst> first, 
    IEnumerable<TSecond> second, 
    Func<TFirst, TSecond, TResult> resultSelector,
    TFirst padFirst,
    TSecond padSecond)

---

Originally reported on Google Code with ID 6

Reported by @cammerman on 2009-02-16 03:05:10

[atifaziz]

"overrides" in my original note should be "override". Didn't mean to imply existing methods should be replaced, but rather just a new one should be added.

---

Reported by @cammerman on 2009-02-16 03:54:04

[atifaziz]

I can't see how you get away without the overload taking a strategy - you still need to differentiate between Pad, Truncate and Fail. How would you make the above signature handle truncation and failure?

---

Reported by @jskeet on 2009-02-16 07:37:42

[atifaziz]

My thought was that adding the pad argument to the existing methods would overcomplicate the signature because it's only necessary for one of the three strategies. The signature I specified above would be a separate overload from the ones already there.

---

Reported by @cammerman on 2009-02-16 13:14:30

[atifaziz]

When I originally submitted the Zip implementation, I intentionally left a comment that referenced a similar discussion regarding zip in Python 3000 as food for thought. Since the comment has been lost in translation, :) I'll re-iterate it here:

[Python-3000] have zip() raise exception for sequences of different lengths

The discussion is very interesting and worth reading up on before settling here.

The current use of an enumeration (ImbalancedZipStartegy) to express the required behavior seems awkward because it's not something you want to be able to vary externally, which is usually why you would make a parameter or argument. Plus, it's a little cumbersome to write and read back in code and not very LINQ-ish in spirit. The enumeration could certainly be used internally for sharing the implementation logic but the public API should use distinct and clear operator names that imply the strategy. For example:

• EquiZip: Sequences must be equal in length otherwise throw error
• Zip: Truncates to shorter of the two sequences
• ZipLongest: Uses longer of the two sequences while padding shorter of the two

---

Reported by @atifaziz on 2009-02-16 17:19:13

[atifaziz]

---

Reported by @atifaziz on 2009-02-16 23:05:00

[atifaziz]

I agree with Aziz that using the strategy enum seems like it might be more cumbersome with little added value for the API consumer... This doesn't mean we wouldn't want to expose it or use it internally, just that simpler methods might be warranted as well.

I think we could conceivably condense all behavior into two methods both named Zip...

One method would either truncate or throw, if the sequences aren't of the same length:

void Zip(this IEnumerable<T1> src, IEnumerable<T2> other, Boolean throwIfUneven)

The other would take generators for each sequence in case one should be shorter, and if the generator is null, use the "default" for that type:

void Zip(this IEnumerable<T1> src, IEnumerable<T2> other, Func<T1> srcPadGen,

Func otherPadGen)

---

Reported by @cammerman on 2009-02-17 00:35:26

[atifaziz]

I removed the comment about Python on the grounds that I'd implemented the optional functionality, and referring to Python probably wouldn't actually help our users :)

Personally I still think the enumeration is the simplest way to go - using a boolean for throw or not feels like the kind of thing that reduces readability: when looking at the code in 6 months time, you'd be pretty much required to check what that parameter was.

I can see the benefit in the padding generators in that it allows a non-default padding, but that's all - and I suspect you'd rarely want to actually express both, because you'd probably know which is going to be longer.

Don't forget that in the current setup the client doesn't have to specify the enum at all - it defaults to Truncate.

---

Reported by @jskeet on 2009-02-17 06:27:42

[atifaziz]

Fair point on readability for the boolean argument.

It's anecdotal, but in my personal use I far more often want to pad the short side than truncate the long side. I use the generators all the time. I have no qualms about making truncate the default behavior, but I think the generator versions would also get a good amount of use.

Especially when working through the IEnumerable interface rather than directly with List, Array, etc., it's not at all uncommon to not know which side is longer before zipping. In fact, needing to know ahead of time I think sort of defeats the purpose of the deferred execution.

If we want to support padding generators, we'd pretty much have to require both to be provided (at least filled in with a null to indicate default), because the way generics works would prevent us from specifying one overload for each side. (They'd conflict with each other when the element types are the same.)

---

Reported by @cammerman on 2009-02-17 14:34:54

[atifaziz]

referring to Python probably wouldn't actually help our users :)

I was more thinking of MoreLINQ developers and maintainers until we polish (docs) for 1.0. :) Meanwhile, is the MoreLINQ audience Mort or Elvis? ;)

Personally I still think the enumeration is the simplest way to go

We risk going on forever with personal preferences and subjectivity. The right solution may be simple, but we may not be there yet. :)

The argument is no longer whether we should provide the functionality or not, but rather how to expose it and using what signature(s). There's already agreement that a Boolean definitely reduces readability. The next thing that should be avoided is an explosion of overloads to do and mean everything. As for the ImbalancedZipStrategy, I've pointed out before that making the strategy an argument of the operator via an enumeration (or even polymorphic type) would be interesting if the problem that needed solving was that the strategy is a variable of the run-time. I think we can
also agree that's not the case here. If that's not convincing by itself, then there is a very subtle yet major idea behind extension methods and LINQ that the enumeration works against. If the enumerable source type wants to provide an optimization for an operator, it can do so by providing a method by the same name and signature as the operator in question. If we use an enumeration that comes from MoreLINQ then the other type has to take in a dependency that won't be looked upon lightly. If we take the approach of embodying the strategy in the name (assuming this is a compile-time decision), then we have simple signatures with Zip, EquiZip and ZipLongest being distinct and clear names. Now, if I have a type called SuperDuperList<T> that wants to provide an optimization for Zip, EquiZip and ZipLongest (or any one of the three) then I can do so using simply base and generic types. Right now, with the enumeration, I have no choice but to support all strategies and take a hit on MoreLINQ! Think about it. This is how Enumerable.Contains works. When using Contains on variant typed as List<T> or IList<T>, the LINQ extension method is not used! If one wants to force use of the LINQ's Contains implementation then one has to hop over AsEnumerable first. So to stay objective, we need to see which approach doesn't take us to far away from how LINQ operators should be designed, taking built-in ones as guidance.

---

Reported by @atifaziz on 2009-02-17 15:39:07

[atifaziz]

I don't want to resurrect any painful discussions here, but unless you envisage more than the three strategies already specified, I prefer the idea of the strategy being inferred by the method name.

• Zip
• PaddedZip

I don't think the truncated version is required because if you lazily evaluate the results of Zip and PaddedZip you can just do PaddedZip.Take or Zip.Take to get the shorter of the two.

---

Reported by jeffmagic on 2009-03-10 22:05:57

[atifaziz]

@jeffmagic: You've got my vote on strategy being part of the method name. ;)

---

Reported by @atifaziz on 2009-03-10 23:05:37