Careful with those enumerables

Careful with those enumerables

Ever since .Net 2.0 introduced the yield keyword for creating enumerators, and even more after the introduction of LINQ in C# 3.0, I've seen more and more APIs return IEnumerable<T> instead of IList<T> or ICollection<T> or their older cousins the ArrayList and the array object.

That makes sense most of the time, especially for collections that aren't meant to be modified, and choosing between those different return types is not what I'm about to discuss here. You can find endless articles and threads about that.

I'm a big sinner when it comes to IEnumerable. Need to remember that lazy evaluation can lead to unexpected side-effects.

Demystifying LINQ Aggregates

This post aims to dissect the power that exists in the Aggregate LINQ operator. I have realized that most programmers use it sparingly and have decided to put a couple of examples to clarify how you can use the Aggregate operator to perform a few tricks.

The author makes the assertion that the Aggregate operator is a bit confusing and rarely used. In my case, I know she's right. Good post to intro this guy to using Aggregates.

Introduction to the Reactive Framework Part V

In the previous post of the Introduction to the Reactive Framework series, we covered how to create new IObservable<T> instances, either from scratch or from existing sequences.  What this allowed us to do was turn an operation which was previously interactive, such as iterating over a collection, to a reactive, where I could have multiple listeners reacting to the same collection concurrently.  This has nice implications for allowing us to scale our application in interesting ways.  This time, let’s take another angle on making asynchronous programming easier.

Just more IObservable goodness. Though, I'm not sure I like the way the ending LINQ statement looks.

I guess a more Clean Code way would be to hide some of the subqueries behind methods.