Explore Posterous

Exploring Interactive

Early on in this series, we covered that when talking about the Reactive Extensions, we were really talking about the traditional interactive programming in the form of the Iterator Pattern and reactive programming with the Observer Pattern.  Erik and his team went about to implement most of the LINQ operators from LINQ to objects onto the Reactive Extensions, but along the way found there were interesting ones that could immediately apply to IObservable<T> instances that had not been implemented yet on IEnumerable<T>.  So, then they decided, to work backwards and take the implementations of these new extension methods on IObservable<T> and apply them to IEnumerable<T>.  Let’s start exploring some of these below in the EnumerableEx class.

All of these extensions really get the mind grapes growing.

Having written a Java bit torrent client years ago (well, most of it, IT WORKED) I always fancy the idea of doing it again in C#. Though I can't think of anything more useful than what people have already done.

I really need to use AOP more and more for logging, security, etc. Doing without it is so painful.

Microsoft seems to be throwing just about everything else into C#, why not some aspects?

The guide is intended to help developers and solution architects design and build effective, high quality applications using the Microsoft platform and the .NET Framework more quickly and with less risk; it provides guidance for using architecture principles, design principles, and patterns that are tried and trusted. The guidance is presented in sections that correspond to major architecture and design focus points. It is designed to be used as a reference resource or to be read from beginning to end.

New and updated, it seems.

It's good to have a general reference. If only things like Rich Internet Application were there in the first edition, I wouldn't have been fumbling around in the dark trying to convince people of things. Now I can just say "Microsoft says so."

I have written far too many null checks in my life. Why do we have even null values? They only seem to provoke a NullReferenceException in our code after all. F# for example has the option type with the value None which is semantically the same as null without being null which makes it impossible to access invalid values by accident. It is of course possible to create null values in F# but it is not the most natural thing in a functional programming language.

Alois Kraus complains about null checks and has some code ideas to get around it. Using an extension method with a lambda doesn't feel like a good solution though.

Ultimately, he wants a language change to have a reference type be suffixed by ? to mean "if not null then run this method or property." That might could work.

Another idea I saw in a language...I forget in which but I believe it was related to me reading up on Google's Go language. Anyways, the idea is that nothing can be null unless you explicitly mark it as nullable. Which means, Nullable Types work make since for reference types and a reference typed variable could never be set to null.

This would definitely be more explicit (ding) and it would confirm to the Clean Code idea of never setting anything to null.

Testable Java
It's often hard to retrofit unit tests in code that wasn't designed to be testable. In this paper, Michael Feathers describes a simple rule that you can use during development to assess the testability of your Java code.

Michael Feathers wrote a FANTASTIC rule to remember when writing code to make it easy to test. His example case is Java but the rules can easily be adapted to C#. I need to train myself to remember this.

I should also get around to reading the his book that I bought.

Behind the scenes of the C# yield keyword

June 9, 2008 by Lars Corneliussen

After reading the great article about the code-saving yield keyword “Give way to the yield keyword” by Shay Friedman I thought it could be interesting to know how the yield keyword works behind the scenes.

…it doesn’t really end the method’s execution. yield return pauses the method execution and the next time you call it (for the next enumeration value), the method will continue to execute from the last yield return call. It sounds a bit confusing I think… (ShayF)

By using yield return within a method that returns IEnumerable or IEnumerator the language feature is activated.

Note: IEnumerable is kind of a stateless factory for Enumerators. IEnumerable.GetEnumerator() is thread safe and can be called multiple times, while the returned stateful Enumerator is just a helper for enumerating contained values once. By contract IEnumerator offers a Reset() method, but many implementations just throw a NotSupportedException.

I found this good little behind the scenes article when just now noticing what the Fault keyword in MSIL was supposed to mean. Hint: it says at the bottom.

Something I should have referenced months ago that a co-worker pointed out to me. Finally, I can get organized samples and understand related items without fumbling through Reflector and the code docs.

I know, I'm way behind on this one

I just learned that the C# compiler is being ported to C# and the VB.NET compiler is being ported to VB.NET. (Right now they are both written in C++, of course :-))

The compiler statement is very interesting. The talk of including asynchronous features into the language itself is also welcome news.

The news of the dynamic keyword is old and horrible. I still assume it was to appease COM users. They just should have locked it down more.