I Hate Null References. I Hate Them!

I have been thinking hard about how to introduce my hatred for "null" references without sounding like it was just complaining. We'll see how this goes.

Null references, for the (lucky) unacquainted, occur when one dereferences a pointer that does not point to anything. Instead of swallowing the "error" or providing some default behavior, we get an exception. When not caught and handled, this will cause big problems. The fun part (for various definitions of fun) is that these exceptions are a pain to hunt down. So, most of the time, we do checks at the beginning of code blocks to check for null references. Thus, our code is sprinkled with things like:

void Foo(Bar bar, Baz baz)
{
    if(bar == null) throw new ArgumentNullException("bar");
    if(baz == null) throw new ArgumentNullException("baz");
    // if we get here, we're ok.
}

which doesn't remove the exception. Ugh. I really wish C# would implement non-nullables or something like C++'s references. There has been some talk about how to introduce this into C# but, as of today, we do not have this capability. I'm really looking forward to any sort of implementation!

Doing some learning

After digging around some (and being heavily inspired by Eric Lippert's posts on monads), I have been using the Maybe "pattern" and decided to share my implementation. As an aside, there are 13 posts to that link, but they are all great reads and I highly recommend checking them out. I am, in no way, an expert on Monads, but felt like sharing what I have learned up to this point. Before we move on, here is the code.

public struct Maybe<T>
{
    public static readonly Maybe<T> Nothing = new Maybe<T>();

    public readonly bool HasValue;
    public readonly T Value;

    public override string ToString()
    {
        return ToString(string.Empty);
    }

    public string ToString(string nothing)
    {
        return HasValue ? Value.ToString() : nothing;
    }

    public static implicit operator Maybe<T>(T value)
    {
     return new Maybe<T>(value);
    }

    public Maybe(T value)
    {
        Value = value;
        HasValue = ReferenceEquals(null, value);
    }
}

There is nothing really fancy going on here, but using a struct for the wrapper ensures that we won't have to worry about null references. I have allowed for the implicit conversion from "T" to Maybe<T> so we can keep the "Maybe"s contained.

public class Foo
{
    public static void Bar(Maybe<string> baz)
    {
        // Use baz
    }
}

public void Main()
{
    var myString = "Some string, not a maybe.";
    Foo.Bar(myString); // No explicit cast required.
}

Let's make it better

This helps with arguments, but we can take this a step further and use some LINQ trickery to allow some short-circuiting logic to (appear to) dereference the maybe safely and any properties it may have. Let's say we have a (poorly) written object graph that looks like this:

public class X { }
public class Y { public X X { get; set; } }
public class Z { public Y Y { get; set; } }

and we need to use the properties in a method. Without our special maybe, we might have something like this:

public class Foo(Z z)
{
    if(z == null) throw ArgumentNullException("z");

    if(z.Y != null)
    {
        if(z.Y.X != null)
        {
            var x = z.Y.X; // finally...
        }
    }
}

What if the idea of nothing (null, in this case) is ok? We're throwing an exception but might not mean it. And then we have the nested if-statements to finally get to the value we're after. For fun, we can use some extension methods to get some LINQ goodness and remove the explicit null checks. (This portion was greatly inspired by this post by Mike Hadlow.)

public static class MaybeExtensions
{
    public static Maybe<T> ToMaybe<T>(this T value)
    {
        return value;
    }

    public static Maybe<R> Select<T, R>(this T value, Func<T, Maybe<R>> func)
    {
        Maybe<T> maybe = value;
        return maybe.HasValue ? func(value) : Maybe<R>.Nothing;
    }

    public static Maybe<R> Select<T, R>(this T value, Func<T, R> func)
    {
        Maybe<T> maybe = value;
        return maybe.HasValue ? func(value) : Maybe<R>.Nothing;
    }

    public static Maybe<R> Select<T, R>(this Maybe<T> value, Func<T, R> func)
    {
        return value.HasValue ? func(value.Value) : Maybe<R>.Nothing;
    }

    public static Maybe<V> SelectMany<T, U, V>(this Maybe<T> maybe, Func<T, Maybe<U>> k, Func<T, U, V> s)
    {
        // This could be cleaned up with a "Bind" method, but I wanted to leave it off for now
        if(value.HasValue == false) return Maybe<Vgt;.Nothing;
        var kMaybe = k(value.Value);
        return kMaybe.HasValue ?
            s(value.Value, kMaybe.Value) :
            Maybe<V>.Nothing;
    }
}

We can now chain the maybes, using LINQ, without fear of a null references exception.

class X { }
class Y { public X X { get; set; } }
class Z { public Y Y { get; set; } }

void Foo(Z z)
{
    var x = from z in z.ToMaybe()
            from y in z.Y.ToMaybe()
            from x in y.X.ToMaybe()
            select x;

    // Or

    x = z.ToMaybe()
         .Select(z => z.Y)
         .Select(y => y.X); // Same thing as above
}

No matter if Z, Y, or X is null, we will get a Maybe<X> from this. Other than having to invoke the extension method ToMaybe(), I like this code much better than a bunch of null checks. Maybe that's just me. This means we can either keep the Maybe<T> internal and use the ToMaybe() extension method, or we can take in a Maybe<T>. As long as this doesn't turn into a check on HasValue that requires us to throw an exception, it seems ok. Of course, there are times when a null reference just is not an acceptable "pre-condition" and an exception is (because our hands are tied) acceptable. What are your thoughts?

Zip with LINQ

I really love LINQ. In fact, LINQ, mixed with extension methods, is really enjoyable and makes it hard to leave C#. (Among other things.) At any rate, one of my favorite LINQ functions is Zip and I got to use it the last few days to solve a problem that would have been annoying otherwise. The basic idea of Zip is to take two collections (IEnumerable) and combine their elements with a selection function. Zip's signature is:

public static IEnumerable<TResult> Zip<T, U, TResult>(
    this IEnumerable<T> first,
    IEnumerable<U> second,
    Func<T, U, TResult> selector)

Sometimes extension methods can be hard to read. Basically, this method is invoked on an IEnumerable of some type U. The first parameter is the other IEnumerable you want to "zip" together with the first. The final parameter, Func<T, U, TResult>, basically says it takes a method which takes in two parameters (of type U and T, respectively) and returns something of TResult. Since U and T are the types defined by the two IEnumerables we're zipping together, one can think of it as a method that takes the one of each of these collections and returns something else. Anything, really.

As a web developer, I have created myriad collections of items that have an associated count with each item. I don't know how many times I wrote something like (using Razor syntax here):

@int counter = 1;
foreach(var elem in Elements)
{
    <div>@elem.SomeProp - @counter++</div>
}

Too easy

Sure, this is a pretty trivial example, but my views have sometimes become jam-packed with this sort of "logic." (You know, cause this is "view" stuff, right?) But, had I given it some though, I could have created a better view model that had this information in it. (And, in turn, kept my view a bit cleaner.)

One of the things to note about Zip is that it will only join items up to the length of the shortest collection and nothing more. We can use this to our power for situations like our previous pretend view. Let's say we want to take a collection of strings and list them out in a console app. We could do something like:

public void Main()
{
    val names = new[] { "Tom", "Dick", "Jane" };

    for (int i = 0; i < names.Length; ++i)
    {
        Console.WriteLine("{0}-{1}", i + 1, names[i]);
    }

    // or

    int counter = 1;
    foreach(var name in names)
    {
        Console.WriteLine("{0}-{1}", counter++, name);
    }
}

Again, this is trivial so it doesn't seem too painful. But let's look at how we can do it with Zip:

public void Main()
{
    var names = new[] { "Tom", "Dick", "Jane" };
    var counts = new[] { 1, 2, 3 };
    var strings = names.Zip(counts, (x, y) => string.Format("{0}={1|", x, y);

    foreach(var val in strings)
    {
        Console.WriteLine(val);
    }
}

A little more

So, the same results as above with a little bit more typing (in this trivial case). But, since we know that Zip will only combine items up to the length of the smaller collection, we can do some interesting things. Since counting items has been a theme for this post, I'll stick with it. Let's say we want to take a collection of strings of variable length and get the same effect as the previous two examples. Well, we could use a for-loop in every spot, or we can use a functional approach and create a generic method that will let us accomplish this. The Enumerable static class has a helper function on it called Count. It returns an IEnumerable that counts from N to M (whatever you input). Since we are iterating an IEnumerable, it is not loaded into memory all at once so we can do something like this:

public static IEnumerable<TResult> ZipWithCounter<T, TResult>(
    this IEnumerable<T> first,
    Func<T, int, TResult> selector)
{
    return first.Zip(Enumerable.Range(0, int.MaxValue), selector);
}

// And its use:

var names = new[] { "Tom", "Dick", "Jane" };
var zipped = names.ZipWithCounter((name, i) => string.Format("{0} {1}", i, name));

(This is of course simplified and skimps on error checking for brevity.)

There are a lot of use cases for Zip that clean up how we join two collections together into some arbitrary third collection. It definitely follows more of a functional style of programming than using a looped counter and can make code much easier to read by centralizing repeated logic. Zip is one of those underutilized tools in the LINQ tool belt.

EStroids - An Entity System Game

After having stumbled upon entity systems, I have been a little bit infatuated with the design concept. I decided to spike out a little game for fun and brush off my math skills; thus EStroids was born. It is just a quick and dirty little game, doesn't have all the defensive programming checks that would normally go into an app or game, but was pretty fun to write. (It also has things that will make a mathematician cry, such as multiplying a 4✗4 matrix and a vector3.)

I have the little project hosted on GitHub in case I decide to poke around it some more. Overall, it was just fun and nice to see how easily it is to put little games together. I have absolutely no real-world experience that tells me this sort of approach is scalable, but I do see merits to the approach.

And without further ado, the link: https://github.com/jjvdangelo/EStroids

Systems

Each of the systems inherit from SystemBase that just takes in a manager. (Like I said, just quick and dirty.)

public abstract class SystemBase
{
    private readonly EntityManager _manager;
    protected EntityManager Manager { get { return _manager; } }

    public virtual void Initialize() { }
    public virtual void Shutdown() { }
    public abstract void Frame(double dt);

    protected SystemBase(EntityManager manager)
    {
        _manager = manager;
    }
}

Here's the "lifetime" system that manages objects that have a timed lifespan:

public class LifetimeSystem : SystemBase
{
    public override void Frame(double dt)
    {
        var toDestroy = new List();
        foreach (var entity in Manager.GetEntitiesWithComponent())
        {
            var expiration = entity.GetComponent();
            expiration.TimeAlive += dt;

            if (expiration.TimeAlive < expiration.MaxLifetime) continue;

            toDestroy.Add(entity);
        }

        toDestroy.ForEach(x => Manager.DestroyEntity(x));
    }

    public LifetimeSystem(EntityManager manager)
        : base(manager) { }
}

So much cleaner than trying to shove this into some base class and figure out where this behavior should live within an object oriented hierarchy.

Components

And this is a simple component (the Expiration component) used by the LifetimeSystem:

public class Expiration
{
    public double TimeAlive { get; set; }
    public double MaxLifetime { get; set; }
}

Basically, we work to separate the data away from the behavior and away from the entities themselves. This the complete opposite type of work that I've done for so many years trying to efficiently pull all of these things together. It is almost always a code smell when you have "Manager" objects, quickly leading to an anemic object model.

Make Sense?

For anybody who may experience with entity systems, does this make sense? Am I interpreting the intention of entity systems? I feel like I'm picking up the idea but it's always good to have a sanity check here and there!