I’ve finally decided to get in on that sweet, sweet Roslyn action and write myself an analyzer (please forgive the American spelling–since I’m programming against a series of types defined in American I’ve decided to use their spelling).
You’ll probably know I’m a big fan of functional programming and I’m trying to write my C# in a more functional style; I’ve found that you can get many of the benefits of functional programming even though you’re not writing in a functional language.
As it turns out, sometimes removing certain features from your programming language (or, at least, disallowing certain actions) can actually improve your code. An easy example of this is the goto statement; despite the fact that the C# language supports goto nobody uses it because it’s widely regarded as a harmful thing to do.
Update: I now have a project on GitHub containing this code at https://github.com/Richiban/Richiban.Func Check this repository for up to date code.
Continuing with my long-running train of thought in bringing some functional programming concepts to my C# projects, I have implemented a type called Optional, roughly equivalent to `Option` from F# or `Maybe a` from Haskell. If you’re not familiar with these concepts, then imagine Nullable from .NET, but applicable to all types (not just value types). The whole idea is that, rather than using a null reference of T to represent a missing value you use a new type–Optional–that can exist in one of two states: it either contains a value of T or does not.
This is a very important difference that I will explain over the course of this post. First, let’s look at the type definition itself. It’s quite long, so feel free to skim-read it at this point and refer back to it at later points in the post.
Primitive obsession is, like many facets of modern programming, something that has been written about many times before (e.g. http://sourcemaking.com/refactoring/primitive-obsession, http://blog.thecodewhisperer.com/2013/03/04/primitive-obsession-obsession/), yet still we see its ensnaring of unwary programmers.
Since C# 6.0 is now feature-locked (and I can’t wait) it’s time to start talking about something that might be in the next version, assumedly called C# 7.0.
The big feature for me would be to get C# to help us write immutable code. That means they need to make it easy to write immutable classes (see my last post on Record types) and immutable local variables too.
I propose the following syntax:
With the impending release of C# 6.0 and all its new features, I have been thinking about what might come in the next version of C# (v7.0, I’m guessing). There has been talk in the Roslyn forums about things such as pattern matching and record types (the latter being especially important since the primary constructors feature was dropped from C# 6.0).
Below is a quick sketch of how I think record classes should work in C#. You can probably tell that I spend a lot of time programming functionally, because I’ve included a number of syntax features here to make immutability a very easy option.
Last week I went on a photowalk with friends. The idea is that people with a shared interest in photography meet up and walk along a pre-prepared path, taking pictures as they go. The walk started at the Hays Galleria near London Bridge and we continued through the Inner London Pool starting on the South side of the river and travelling over to the North side and back again.
Along the way we took in some of London’s finest landmarks through the back streets finding views of London Bridge, the Shard, the Tower of London, Monument and more. This one was part of the Kelby Worldwide Walks and there was a competition to go with it.
I have included a gallery of the shots I took (and decided to keep), and the photo I entered into the competition too.
A few days ago I ran an introduction to F# course for colleagues at work. The idea of the course was to explain the basics of F# including syntax, programming style and the FSI window, as well as to get people excited. I didn’t correctly judge how long the presentation would take (people were asking lots of questions as I went, which is good!), so I ended up splitting it up into two parts. Here I am publishing a rough written copy of the presentation, compiled from my notes that I worked from as I talked, for you to peruse. It’s somewhat rough, but for those who were there it should serve as a reminder. Next time we will talk through some worked examples of Fizzbuzz & fizzbuzzbaz, we will cover types (classes, structs, interfaces, enums, records, units of measure and discriminated unions). We will also go through some application design, such as: MVC, DDD, CQRS, WTFBBQ.