.NET 4 version with duplicates removed (e.g. Zip)

[GoogleCodeExporter]

Upgrading a project from .NET 3.5 to 4, Zip gave us a headache due to that 
Microsoft now supplies a Zip extension method 
(http://msdn.microsoft.com/en-us/library/dd267698.aspx).

How about a MoreLINQ version targeted for .NET 4 with Zip, and other duplicates 
removed (if any)?

Original issue reported on code.google.com by martin.r...@gmail.com on 17 Aug 2010 at 11:55

[GoogleCodeExporter]

Original comment by azizatif on 25 May 2012 at 6:30

• Changed state: Accepted
• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

There's always potential for conflict with some future version of .NET or 
another similar library so ideally we would come up with a future-proof and 
conflict-free solution that put's the user in control.

At present, when you import the MoreLinq namespace, you get all operators 
whether you like it or not. What would be helpful is to be able to choose 
exactly the operators one would like to import and avoid those that are not 
needed or would otherwise conflict with either the .NET Framework or another 
library referenced in the user's project. This could be done by breaking up 
MoreEnumerable into distinct classes (as opposed to the single partial class it 
is today), hosting only a single operator along with its overloads. Each 
MoreEnumerable class would then be wrapped in a namespace named after the 
operator it hosts.

The attached source illustrates this approach (also posted online[1]). Adding 
it to the current MoreLinq project has the effect of making both options 
available. The user could import MoreLinq namespace as today and be done with 
it. Alternatively there's a new NoConflict namespace (in the spirit of jQuery) 
that uses the new approach with some select operators, and using which, the 
user would import MoreLinq.NoConflict.DistinctBy just to bring in and use that 
operator.

The NoConflict approach has the benefit of providing the conflict-prone or 
conflict-free option to the user while maintaining backward compatibility. 
However, it does complicate the life of MoreLINQ contributors going forward for 
these reasons:

- The signatures have to be duplicated and kept in sync
- The XML doc would have to be duplicated and kept in sync
- The conflict-free, forwarding, implementations of the operators won't be 
tested, meaning there's a small chance that they incorrectly call the base 
implementations

In light of the above, one could break compatibility with the 1.0 beta version 
that's been released and in use in field and simply go with the conflict-free 
approach.

[1] https://gist.github.com/2869531

Original comment by azizatif on 4 Jun 2012 at 5:25

Attachments:

• NoConflict.cs

[GoogleCodeExporter]

While I can see the benefits, I don't think they're worth the downsides. The 
effort required to keep this up to date will be greater than the effort 
required to spot new collisions, IMO.

My preference would be to just have two builds.

Original comment by jonathan.skeet on 10 Jun 2012 at 8:33

[GoogleCodeExporter]

I agree that this should not be solved using a "per operator" namespace 
separation. It is possible that conflicts will occur at the operator overload 
level. The level of granularity needed to be future-proof is not practical.
Additionally, the number of namespace imports in the client code files would be 
substantial and would also make exploration by intellisense impractical.
Also, you don't get the conflicts until you actually try to use the conflicting 
operator. Therefore, many users could end up importing MoreLinq and then 
avoiding the conflicting operators so that they don't have to invert their 
entire namespace import. Not a low friction user experience. 
Also, there are probably lots of people enjoying LINQ who have little knowledge 
how extension methods are resolved. I use LINQPad (with DSL dll's) as a sort of 
LINQ2DSL engine. The consumers of that DSL use C# and LINQ, but aren't 
programmers.

I was originally thinking that the conflicts could be avoided using namespaces. 
Not on a per operator basis, but .NET version compatibility. But I am now 
leaning in the direction of one build per .NET version to avoid continuously 
breaking clients by moving stuff and hiding neat stuff from intellisense in not 
imported namespaces.

The current user experience is one binary reference and one namespace import. 
Let's keep it that way.

Original comment by tormod.s...@gmail.com on 16 Jun 2012 at 10:49

[GoogleCodeExporter]

Original comment by azizatif on 12 Jun 2013 at 10:11

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

MoreLINQ does not require two builds so far since all operators continue to 
work fine in .NET Framework 3.5 and removing one operator does not warrant the 
overhead of two builds. Instead, I plan to ship Zip in 2.0 but rename it to 
ZipShortest (to contrast with EquiZip and ZipLongest). I will also be adding 
additional overloads that can be handy but don't exist in the LINQ's version of 
Zip so there's benefit to keeping MoreLINQ's Zip around.

Original comment by azizatif on 22 Jun 2013 at 12:25

[GoogleCodeExporter]

This issue was closed by revision a079bd816594.

Original comment by azizatif on 22 Jun 2013 at 12:31

• Changed state: Fixed