The background should be well known.
When including todays single morelinq distribution in a project, you cannot
invoke the Zip operator in a code block that has included both the System.Linq
and Morelinq namespaces.
You can work around this problem today by either not using them in the same
code block or by using the "per operator" nuget packages.
Adding all the nuget packages for the individual operators is a hassle when
using ad hoc projects or LINQPad. I also think that it is somewhat excessive
engineering to achieve a general solution for what is in all likelihood will be
very few cases.
Todays solution also sets it apart from regular LINQ operators as Morelinq
operators will not be laying around in intellisense waiting to be
used/investigated. If intellisense does not show "ToDelimitedString", would you
really browse nuget for it? How would you know the exact spelling without the
partial matching of intellisense? Do you expect people to frequent the project
web site in search of new operators? I have little doubt that this slows down
the adoption of new operators. A project like this is also about educating
people into functional thinking.
I suggest a breaking change that Zip should be removed from the main branch and
available as separate nuget package.
Alternatively a separate .NET4 distribution. It's not like .NET4 is a new
novelty anymore.
Alternatively (2), the license should allow removal of source code (commenting
out zip operator) without all the end user notifications requirements clicking
in place.
I make dll's for tooling (mostly internal use), and the license terms that
applies for modified source code (distributed notice, source code availability,
help->about info) that would have to accompany every tiny .exe file is not
trivial to achieve in a large company.
Thank you. I love morelinq.
Original issue reported on code.google.com by tormod.s...@gmail.com on 30 Jan 2014 at 9:07
Original issue reported on code.google.com by
tormod.s...@gmail.comon 30 Jan 2014 at 9:07