I just published the first source for “Dizzy” my new library of higher order methods. Its focus right now is on lists, which is the reason I called it dizzy. Looping through lists makes me think of spinning, which in turns makes me think dizzy. I thought it was clever! Anyways, I have pushed the project with just a very few methods. I am using NUnit and right now I have 100% unit test coverage which is easy since they are just library method calls.
Right now I have a total of 5 methods. They are Map, ForEach, Filter, Repeat, and Cycle. More will be added in the next few days and I will blog about methods as I add them. Right now I am looking at adding the usual list processing methods from other languages, but if you are interested in seeing any particular methods implemented, please let me know. Or implement them yourself and submit them to me!
If you want to check out Dizzy, just click the link!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
Two questions:
1. How useful is it to have names which match existing nomenclature, especially when equivalent functions already exist under different names in .NET 3.5?
For example, Manipulation.Map() is Enumerable.Select(), and Manipulation.Filter() is Enumerable.Where().
Given that the methods are already in .NET (if only by a different name), what is the advantage to using existing nomenclature? Education? Or something else?
2. Would you be interested in merging with another library?
Mono.Rocks (http://www.mono-project.com/Rocks) is an effort to maintain a variety of useful extension methods, and already contains your Traversal.Repeat() as Mono.Rocks.IEnumerableRocks.Repeat().
(Furthermore, your Traversal.Repeat() is buggy, as the argument checking exceptions won’t be generated until .MoveNext() is invoked on the iterator, i.e. argument checking is itself lazy, which I doubt is intentional).
Mono.Rocks is under MIT/X11, which is only slightly more liberal than your current Ms-PL license, if licensing is a concern.
1) My motivations right now are two things. First education, simply writing the library will be a learning exercise for me, secondly, it will allow me to introduce other versions (such as parallel versions) of methods that share the same naming scheme. I full realize that there is overlap with some of the built in linq functionality, but right now that doesn’t really bother me.
As far as Traversal.Repeat being buggy, yes I realize that the argument checking is lazy, and in a future update I will consider wrapping it in a method to force immediate argument checking.
2) Right now I don’t think I am going to merge with another project, but I’d be more than willing to share methods or functions with another project.
2)
Might I suggest following PLinq for the parallel version? That is, instead of having a ParallelMap which is a parallel version of Map, instead have an AsParallel() extension method which returns an IParallelEnumerable<T>, and then create versions of Map() et. al that consume IParallelEnumerable<T>:
[quote]
interface IParallelEnumerable<T> : IEnumerable<T> {}
static class DizzyEnumerable {
class ParallelEnumerable<T> : IParallelEnumerable<T> {
public IEnumerable<T> E;
}
public static IParallelEnumerable<T> AsParallel<T> (this IEnumerable<T> self)
{
return new ParallelEnumerable<T> {E = self;}
}
public static IParallelEnumerable<TRet> Map<TArg, TResult> (
this IParallelEnumerable<T> self,
Func<TArg, TRet> f)
{…}
}
[/quote]
The advantage to doing this is that it’s trivial to convert between the sequential and parallel versions:
[quote]
// sequential:
var e = list.Map (v => v);
// Parallel:
var e = list.AsParallel().Map (v => v);
[/quote]
You’d literally only need to add a single method call within the chain to get the parallel version, as opposed to doing a potentially massive symbol rename of s/Map/ParallelMap/g.
I was actually looking into heading down that route. I appreciate the code and I will see when I can get this into Dizzy.