Description
Note: This is forked from a comment in issue #60.
With extension methods, there's always a potential for conflict with some future version of .NET or another library so following is a proposal to come up with a future-proof and conflict-free solutio 8ACF n that puts the user in control.
At the 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 following sample illustrates this approach:
#pragma warning disable 1591
using System;
using System.Collections.Generic;
namespace MoreLinq
{
namespace NoConflict
{
namespace DistinctBy
{
public static class MoreEnumerable
{
public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source,
Func<TSource, TKey> keySelector)
{
return MoreLinq.MoreEnumerable.DistinctBy(source, keySelector);
}
public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source,
Func<TSource, TKey> keySelector, IEqualityComparer<TKey> comparer)
{
return MoreLinq.MoreEnumerable.DistinctBy(source, keySelector, comparer);
}
}
}
namespace EquiZip
{
public static class MoreEnumerable
{
public static IEnumerable<TResult> EquiZip<TFirst, TSecond, TResult>(this IEnumerable<TFirst> first,
IEnumerable<TSecond> second,
Func<TFirst, TSecond, TResult> resultSelector)
{
return MoreLinq.MoreEnumerable.EquiZip(first, second, resultSelector);
}
}
}
}
}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, it would be best to break compatibility in a future major version and just do with the namespace per method approach (and minus NoConflict).