using Programming;

A Blog about some of the intrinsics related to programming and how one can get the best out of various languages.

F# Advent 2019: Dawn of the F# Domain Types

If you use .NET, build your objects in F#

So towards the end of October, I tweeted (as one does) about building domain objects and models in F#. I mentioned a few nice things about it, so today I intend to do a deeper dive into some of those nice things, and talk about why they are concerns you should keep in the back of your head when you make a decision about how to build your domain models.

Now it's no secret that I like F#. I talk about it a lot (among many other things), largely because when I am doing .NET work, there is almost always some F# involved. (It might be a small portion, or it might be a large portion, depends on the project.) As a result, if you've ever spoke with me in person about programming, I've probably talked about it.

Today, I'm going to show you why F# is a very cool tool in the .NET ecosystem, and how F# fixes a lot of class-oriented things that, in my opinion, C# does wrong.


F# does a lot of the heavy-lifting for object-oriented work

One of the most impressive things I feel F# has to offer is the level of generation it offers for object-oriented work. How it can give you a lot of things you usually spend a good chunk of time on for free. Three lines of F# can do something that would take, genuinely, dozens (or even hundreds) of lines of C#.

If you've ever done OOP work, chances are you've had to write a .ToString(), or a .Equals(object), or a .GetHashCode(). Spoiler alert: with F# you don't need to write any of those most of the time. (You can, but it's ill-advised.)

Let's take a common game-development scenario in C#: vectors. In physics, a vector is a distance and direction. Start at the origin (or point (0,0)), then adjust position from there based on the direction given, and the distance, move to the new location.

Commonly, we represent them in one of two ways:

  • r, Θ
  • x, y

You are likely familiar with the (x, y) format: this is standard point representation for the cartesian coordinate system. The (r, Θ) format is common in polar coordinate systems.

Long-winded math aside, the two values can be translated between. We'll build a sizable Vector2 feature-set into our program, and see how the F# and C# of the implementation vary.

A standard C# starting point might be something like the following:

public class Vector2 
{
    public int X { get; set; }
    public int Y { get; set; }
}

In F#, we would do something like the following:

type Vector2 = {
    X : int
    Y : int
}

Alright, so far F# hasn't really lived up to the promise. It's the same length as the C#, and we don't really see any advantages.

Fair. We haven't done anything to really take advantage of F# yet, but one of the things we already have is an implementation of .ToString(), .Equals(object), and .GetHashCode(). It also implements IEquatable<Vector2>, IStructuralEquatable, IComparable<Vector2>, IStructuralComparable, and IComparable.

I could go into a large digression on the intermediate language generated and how it works, why it's important, etc., instead, I'm going to just use a quick screenshot of the generated F# class (left) to the generated C# class (right).

F# and C# comparison

Wow are those different. F# implemented 9 additional methods and even setup a constructor for us. Not so bad. The C# version, on the other hand, is just the two properties. So really, our 4 lines of F# is equivalent to a lot, lot more in C#. In fact, the F# version is even immutable. Sure, we could omit the set in the C# to achieve the same, but then we have to define our own constructor. My point with this first example is to demonstrate how effective F# is at generation. We'll dig deeper into what it means in a few moments.

Now, I could stop here, and I suppose if I were publishing this right now I might, but today I'm going to go a little further.


Why is all this F# generation important?

This is probably the more important part to discuss: why is the generation F# provides so important? Why do I push it as such a major reason to build objects in F#?

It all boils down to a couple basic points:

  1. Structural equality and comparison is important for doing effective matching and evaluation of objects against one-another.
  2. These few functions are extremely important if the object itself is to be used in a HashMap scenario. (I.e. a dictionary key, etc.)

Basically, it boils down to performance and developer ease. A lot of times we want to be able to do something like if a = b then ..., but we find out that there is no = operator between a and b, even when a and b are the same type. So you go ahead and define your own operator, just to need to define a .Equals(object) method and then .GetHashCode(). You will also want both of these implemented if you are using LINQ, as some of the LINQ methods / query syntax require them.

Unfortunately, in C# we don't get those features. Instead we only have a base implementation (the default) for both Equals(object) and GetHashCode(). The base implementations don't do structural equality at all, so two objects that are exactly the same might not match via .Equals(object). (Spoiler: unless they are the exact same instance, they won't match via the default.)

This also comes in to heavy play with struct types, as it's expected that two structures (which are expected to be value types) that are instanced via the same values would be the same. But alas, by default, they are not such in .NET.

So, let's look at some situations we would have to write a lot of manual code for in C#, that F# just gives us.

Scenario 1: you want to determine if an element is in an array.

Let's assume you have an array of elements, and you want to determine if you have a certain element in the array. With the new LINQ syntax in C#, it should be rather simple, no?

var find = new Vector2() { X = 1, Y = 2 };
var results = elements.Where(x => x.Equals(find));

Seems reasonable, should work fine. Except it wont. The problem here is that we don't override .Equals(object), and we don't have a .Equals(Vector2), so our default C# version won't work. Our F# version will work fine though, as we have both of those options in the F# version. One note: for the F# version we must initialize find via the constructor, because it's immutable (which lends well to a later point).

To get the C# version to work, we really just need to pick one of the two to implement, though for fairness we'll actually implement both.

public override bool Equals(object other) => Equals(other as Vector2);
public bool Equals(Vector2 other) => other != null && X == other.X && Y == other.Y;    

So we added two lines (at a minimum) to our C# to make sure this works, but we end up with working code, so we are done here.

First note: your IDE might state that you didn't override GetHashCode(), and it's entirely correct! It's always a best practice to override both if you are doing one of them. Second note: you might find that the two lines printed by the C# version are different than the F# version, and they are. The F# version has a custom .ToString() implementation, which means when we do a print line for it, we get a nicer string.

Scenario 2: you have two collections, and you want to create the collection of the elements present in both.

This scenario is your basic Intersect scenario: you have some elements1 in one collection, and some more elements2 in another collection. You want to create a single collection that encompasses only those elements that are present in both collection.

You might write some code like the following:

var results = elementsA.Intersect(elementsB).ToArray();
Console.WriteLine(results.Length);

In the C# version, you'll find that no elements match no matter how you call the Intersect function, and that the F# version gives you some.

Again, we're missing a key piece, I alluded to it earlier: GetHashCode(). We need it for Intersect to work properly.

So, we'll create a poor implementation:

public override int GetHashCode() => X ^ Y;

Now the C# version works fine.

Note here: the F# GetHashCode() is a good implementation, ours was a poor attempt to make sure that we got something in place for .NET to use. In .NET, it's OK for two different elements to return the same code, because Equals(object) is the final decision maker, but two identical elements may NOT return different hash codes.


At this point, I wanted to go into some performance implications of the C# classes vs. the F# generated objects, but because this post is already long, and also because it's Christmas, I'm going to save that discussion for a later date. In fact, I'm going to target mid-January for that discussion. That said, I recommend doing some tests of the C# vs. F# objects, and especially in usage as dictionary keys. You might find some interesting results.

Additionally, this is all up on GitHub, so feel free to play with the exact code I was using to test our setups.

C# Expression-Bodied Members

Using Expression-Bodied Members in C#6.0

So it's been a while since I've written a blog post (far too long if you ask me). I'll not go into too much detail, but I've been busy doing some life things. I recently changed jobs, moved, and started working on a great deal of other projects that just consume all my time, and I haven't had time to share any of my thoughts recently.

With that said, I do have something I wish to talk about at the moment, and that is a new feature found in C#6.0: Expression-Bodied Members.

This feature, in my opinion, is one of the more useful features of the recent language update. It opens a great deal of doors and has shortened a lot of my code substantially, which is always good. (For some reason, we strive to keep the number of characters/lines on our source code to a minimum.) It offers us the ability to take certain methods and properties, which would have otherwise taken up a fair amount of space, and shrink them down to a much more manageable level.

However, before we talk about this feature, we need to talk about all the parts of it. So let's begin with the most important part of an expression-bodied member: the expression.

What is an expression?

We're going to take a definition from webopedia (see http://www.webopedia.com/TERM/E/expression.html) which should sum it up fairly well:

In programming, an expression is any legal combination of symbols that represents a value.

This is a pretty basic definition, but should work to serve our needs quite well. When we use the term expression we mean a fairly simple set of instructions that return a value. Do note: I bolded "return a value" for a reason. If the set of instructions do not return a value, then they are not an expression, and cannot make up an expression-bodied member. (We'll see this isn't entirely true shortly.)

A few examples of what we mean by expressions when discussing them in C#:

2 + 5
x * 4
"EBrown"
name ?? "No Name"
person.ToString()

The last one might surprise you - yes, calling .ToString() on something is an expression, as .ToString() returns a value. The second-to-last might surprise you as well, but it's pretty simple: if name is null, then the expression evaluates to "No Name".

Do note: expressions don't have to return a non-null value. The person.ToString() call above could potentially return a null value, and that's perfectly OK. It's still an expression. The value itself has no bearing on the definition of the term, only whether or not something actually returns a valid value. This is an important concept to bear in mind, as not all of our expressions have non-null values.

So what do expressions usually look like in C#?

Any series of tokens that follow a return token, up to the first subsequent semicolon (;) are an expression. So for all of our examples above, they might look like:

return 2 + 5;
return x * 4;
return "EBrown";
return name ?? "No Name";
return person.ToString();

Mind you, expressions don't have to follow a return statement. Consider that 2+5 is still an expression in the following example:

var myString = "Some string " + (2 + 5).ToString() + " with numbers in it.";

But we also have several other expressions:

2 + 5
(2 + 5).ToString()
"Some string " + (2 + 5).ToString() + " with numbers in it."

All three of these are expressions, in their own right. All three of them also contain other expressions. This is an important concept to understand, in the expression 2 + 5, there are actually two other expressions: 2 and 5. These are both expressions as well.

What does an expression-bodied member look like, in C#?

There are two types of expression-bodied members in C#:

  • Expression-bodied readonly properties;
  • Expression-bodied methods;

Both types of expression-bodied members in C# look something like the following:

member => expression;

It's very simple, you provide a member, the "lambda" sign (=>), and an expression. You can also provide the standard member modifiers in the member itself as well. (Access modifiers, attributes, etc.) It's a regular member, it just uses a different body syntax. You should note that there are no braces in play, it's just a member and expression.

An example of a C# expression-bodied member:

public override string ToString() => $"Name: {Name}";

Note that there is no return statement. An expression-bodied member always returns a value. (Except in the case of void methods.) That is why we just talked about expressions to such detail. We need something to return. Something to give back.

What about void methods?

You can still use an expression-bodied member in a void method, it simply has to have a void return type, or be a disposable call. The following code is completely valid C#6.0:

public void MethodA() { }
public void MethodB() => MethodA(); // `MethodA()` is `void`, and `MethodB()` is `void`
public string MethodC() { return "MethodC"; }
public void MethodD() => MethodC(); // The result of `MethodC()` is disposable

The following is invalid:

public void MethodA() { }
public string MethodB() => MethodA(); // The expression returns a `void` type, but a `string` is expected
public void MethodC() => "MethodC"; // The expression returns a `void` type, but the value is not disposable

An expression-bodied member with a return type can mentally be rewritten as:

member { return expression; }

An expression-bodied member with a void return type can mentally be rewritten as:

member { expression; }

How do I use expression-bodied members?

It's pretty simple to use an expression-bodied member. You have two options: an expression-bodied readonly property, and an expression-bodied method. Both of these are trivial to use, the only difference is a minor issue in syntax.

Just like a normal readonly property, and expression-bodied readonly property only has a get-method within it. The difference is syntax. As we may recall, a normal readonly property may look something like:

public double TotalPrice { get { return Quantity * Price; } }

To convert this to an expression-bodied member, we simply replace the getter with an expression of the previous syntax:

public double TotalPrice => Quantity * Price;

This is a property bodied by an expression. You'll note that there are no parameters passed, so as far as other code is concerned it's treated just like a normal property, that only has a getter.

The only difference between a method and a property being bodied by an expression is that a method has the requisite parenthesis in the definition.

public override string ToString() { return $"Price: {Price}, Quantity: {Quantity}"; }

As a method, could be rewritten as:

public override string ToString() => $"Price: {Price}, Quantity: {Quantity}";

As you can see, in both cases we omitted the return altogether. Properties and methods that specify a non-void return type implicitly return whatever the result of the expression is.

A real life example of the benefits of expression-bodied members

For this I'm going to use a partial copy of a class I wrote for a C# library I'm working on. (I'm omitting all the comments and attributes, for brevity.)

This is (most of) a Rectangle class I wrote in a drawing library (for a clone of Windows Forms for XNA). This first version is the version without expression bodied members at all. You can find the most recent version at: https://github.com/EBrown8534/Framework/blob/master/Evbpc.Framework/Drawing/Rectangle.cs

public struct Rectangle
{
    public Rectangle(Point location, Size size)
    {
        Location = location;
        Size = size;
    }

    public int Bottom { get { return Location.Y + Size.Height; } }
    public bool IsEmpty { get { return this == Empty; } }
    public int Left { get { return Location.X; } }
    public Point Location { get; }
    public int Right { get { return Location.X + Size.Width; } }
    public Size Size { get; }
    public int Top { get { return Location.X; } }

    public override bool Equals(object obj) { return obj is Rectangle && (Rectangle)obj == this; }
    public override int GetHashCode() { return base.GetHashCode(); }

    public override string ToString()
    {
        return $"({Location.X},{Location.Y},{Size.Width},{Size.Height})";
    }

    public static bool operator ==(Rectangle left, Rectangle right)
    {
        return left.Location == right.Location && left.Size == right.Size;
    }

    public static bool operator !=(Rectangle left, Rectangle right)
    {
        return left.Location != right.Location || left.Size != right.Size;
    }

    public static readonly Rectangle Empty = new Rectangle(0, 0, 0, 0);
}

Pretty simple, right? I'm not going to discuss any of the other C#6.0 features that I've used, just know that there are some.

Now, let's see what this looks like if we replace all the smaller methods with expressions.

public struct Rectangle
{
    public Rectangle(Point location, Size size)
    {
        Location = location;
        Size = size;
    }

    public int Bottom => Location.Y + Size.Height;
    public bool IsEmpty => this == Empty;
    public int Left => Location.X;
    public Point Location { get; }
    public int Right => Location.X + Size.Width;
    public Size Size { get; }
    public int Top => Location.Y;

    public override bool Equals(object obj) => obj is Rectangle && (Rectangle)obj == this;
    public override int GetHashCode() => base.GetHashCode();
    public override string ToString() => $"({Location.X},{Location.Y},{Size.Width},{Size.Height})";
    public static bool operator ==(Rectangle left, Rectangle right) => left.Location == right.Location && left.Size == right.Size;
    public static bool operator !=(Rectangle left, Rectangle right) => left.Location != right.Location || left.Size != right.Size;

    public static readonly Rectangle Empty = new Rectangle(0, 0, 0, 0);
}

A little cleaner, yes? The horizontal space of our code has been significantly reduced for most of the methods and properties. A lot of that clutter is now gone.

Limitations of Expresison-Bodied Members

One of the major limitations of expression-bodied members is exception throwing. Exceptions cannot be thrown directly from an expression-bodied member. You can still do things that would throw exceptions, but you cannot actually throw anything. This is due to the fact that throw ... is a statement, rather than an expression.

See this Stack Overflow question and answer for more information on this limitation.

DO's and DON'Ts of Expression-Bodied Members

Here are a few of the general do's and don'ts I use when determining if I can use an expression-bodied member:

  • DO use expression-bodied members on non-auto-implemented readonly properties

    • This helps reduce clutter in code and makes the intention much more explicit. It allows future programmers to see that the property was meant to be explicitly readonly, and that a set clause should never appear for it.


  • DON'T use expression-bodied members on static readonly fields (Empty, etc.)

    • Any static readonly fields should be simple values, which should never change. By rewriting them as expression-bodied members, these simple fields are now properties, and as such slightly more overhead is attributed to them. (Especially in the case of Empty fields.)


  • DO use expression-bodied members on methods with simple return statements

    • Methods that have a single return statement written as expression-bodied methods allow the programmer to be completely explicit about the intention of the method.


  • DON'T use expression-bodied members when the expression contains multiple ternary or null-coalescing operators

    • Expression-bodied members may be used when one of either (or one of both) is found, but should not be used if more than one of either of these is found. This creates confusion and makes debugging the method much more difficult.

And the last one, which you may or may not want to adopt (I have):

  • DON'T use expression-bodied members on void methods, period

    • In the case of void methods, an expression-bodied method is misleading. It tends to hint at the idea that something should be returned (as expressions should always return a value) when in fact nothing is to be returned, by design. It creates confusion among developers.