Another source for LINQ extensions

While poking around for LINQ extensions, I found a project on Google Code, morelinq, that has *numerous* LINQ extensions from some rock-star authors like Jon Skeet, such as:

  • Batch
  • Concat
  • Consume
  • DistinctBy
  • Pad
  • Pipe
  • Scan
  • TakeEvery
  • Zip

And many more.  For those that can’t/won’t download Reactive Extensions, which subsumes nearly all of these, morelinq is a good alternative. What’s even more valuable are a couple of branches that have a number of other really cool extensions, including one I was looking for:

IEnumerable<IEnumerable<TSource>> Partition<TSource>(this IEnumerable<TSource> source, int size)

Pretty sweet…

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in C#. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://peshir.nl/ peSHIr

    Ah, the little morsel I chose to call SplitUp. I guess, if it’s written by Jon Skeet (or another rock-star author ;-) ), that Partition is just as lazy in it’s behavior as my http://peshir.blogspot.com/2011/03/example-code-for-splitup-on-infinite.html is?

  • http://realfiction.net Frank Quednau

    Reactive works off IObservable, so you really should have both ;)

  • http://jorudolph.wordpress.com Johannes Rudolph

    Being one of the guys who worked on that particular piece of code, I can tell you a couple of things about Partition():

    a) It’s not fully finished yet (it’s in the EvenMoreLinq branch which sort of serves as a staging area). There are issues (such as when using it with an infinte sequence of partition sizes)
    b) The source sequence is lazily evaluated, a partition is buffered before it is returned. A buffered partition is returned element by element.

    peSHIr’s implementation will always yield the buffered parition in one go (the full list).

    Implementing LINQ operators is actually not quite as easy as it seems in the first place. The issue we had with MoreLinq is the lack of real world feedback, both in terms of desired features as well as desired behavior, so a lot of ideas we had ended up in that staging area.

    The second aspect is that most operators there haven’t been performance optimized yet, Parition is a good example for that. There’s a lot of headroom for making it faster such as adding selectors, tweaking the buffer and properly letting go of it.

    • Pablo Montilla

      In which ways is Partition() different from System.Linq.EnumerableEx.BufferWithCount() in System.Interactive?

  • Johannes Rudolph

    Being one of the guys who worked on that particular piece of code, I can tell you a couple of things about Partition():

    a) It’s not fully finished yet (it’s in the EvenMoreLinq branch which sort of serves as a staging area). There are issues (such as when using it with an infinte sequence of partition sizes)
    b) The source sequence is lazily evaluated, a partition is buffered before it is returned. A buffered partition is returned element by element.

    peSHIr’s implementation will always yield the buffered parition in one go (the full list).

    Implementing LINQ operators is actually not quite as easy as it seems in the first place. The issue we had with MoreLinq is the lack of real world feedback, both in terms of desired features as well as desired behavior, so a lot of ideas we had ended up in that staging area.

    The second aspect is that most operators there haven’t been performance optimized yet, Parition is a good example for that. There’s a lot of headroom for making it faster such as adding selectors, tweaking the buffer and properly letting go of it.