Poor man’s DI is dead; long live Pure DI

One of the last posts I wrote before disappearing off the face of this blog for nearly two years was “Are IoC Containers a case of ‘The Emperor’s New Clothes’?” there were two main points that I was exploring in this article that bugged me at the time:

  1. All too often, people seem to come up with dreadful implementations of IoC that either exposed all of their application to the container or they used some sort of “God object” container to handle injection into every part of the application.
  2. The way to avoid the above problem was given the rather insulting term “Poor Man’s DI”, which was unhelpful as it naturally discouraged those learning about DI from using it.

Continue reading “Poor man’s DI is dead; long live Pure DI”

Introducing Succinc<T> – functional additions to C#

SuccincT logoTo certain extent, the title of this post is a little dishonest: it’s not really the first time I’ve introduced Succinc<T> on this blog. I first mentioned it over two years ago. To explain the title therefore, some history is required.

During early 2013, I was indulging myself in a “thought experiment” language: Lapsang. One such thought experiment was around the idea of whether a language could sensibly support the concept of not throwing exceptions for petty, unexceptional, reasons. Continue reading “Introducing Succinc<T> — functional additions to C#”

Some thoughts on expanding SuccincT to provide richer interface contracts and auto-generated data classes

SuccincT iconRecently I created a very simple framework, SuccincT. At it’s core is the ISuccess<T> interface. As I explained in a previous post though, by itself that interface isn’t much use. C# lacks the ability to define constraints on an implementation of ISuccess<T>, save through comments. The idea behind it was that an implementation should throw an exception if its Value is read when Success is false, but there is no way to guarantee that an implementation will exhibit this behaviour. This bugs me.

Unrelated to SuccincT, I’m a fan of defining data objects via interfaces, rather than concrete types. By “data object”, I mean any object that encapsulates a set of values. These might be used to avoid multiple parameters to a method or constructor, or to return a complex data set from a method. Data objects need not be immutable or serializable; they just need to be simple to use without causing problems when it comes to testing. As I like to encapsulate data, I like the setters of data objects to be internal, which does cause problems with testing. Thus why I like to use interfaces: the test class can define its own implementation, rather than having to fight against encapsulation. However, for every interface I create, I have to create at least one class too. This adds needless code to projects, which also bugs me.

These two things – wanting interfaces to define a more detailed contract and wanting to avoid having to write data object classes that can be 100% inferred from the interface – set me thinking: could I create some way of extending interfaces and avoiding writing data object classes? Continue reading “Some thoughts on expanding SuccincT to provide richer interface contracts and auto-generated data classes”

C# equality in depth. Part 1: Basic == equality

Equality in C# is an odd beast. At first glance, it seems very simple. Value types are compared by by value, objects are compared by reference and the comparison method can be overridden by a class if it wants to. For example, the String class compares the string contents, rather than comparing by reference. There are also sensible “best practice” rules suggested by Microsoft, such as avoiding comparing mutable objects by value, only by reference. All is not as it seems though as the following series of NUnit tests show. All the tests pass and thus demonstrate some aspect of equality in C#. Continue reading “C# equality in depth. Part 1: Basic == equality”

Posted in C#

C# equality in depth. Part 2: .Equals() and == are not equal

The two ways of checking for equality in C# – using == and .Equals() – can be modified for individual types. It is important to remember though that override and overload are two very different things in C#: .Equals() can be both overridden and overloaded, whereas == can only be overloaded. This set of tests demonstrate the significant effects this subtle difference can have on equality comparisons. Continue reading “C# equality in depth. Part 2: .Equals() and == are not equal”

C# equality in depth. Part 3: IEquatable

With .NET 2.0, Microsoft introduced the IEquatable interface. It introduced a typesafe Equals() method that could be used to speed up comparisons in the new generic collections. It speeded up those comparisons by avoiding the need for casting and boxing, which the Object.Equals() suffered from. The IEquatable interface is a dangerous beast though as it can lure the unwary into thinking it rationalised equality in C#. This set of tests sets out to demonstrate how quite the opposite occurred: it simply made things worse. Continue reading “C# equality in depth. Part 3: IEquatable”

Posted in C#

Structural typing, or did OO get interfaces wrong?

Lapsang logoLately I have been doing a lot of thinking about programming languages and how ideas change over time on what constitutes good language functionality. As I enjoy playing around with grammars and parsers, I naturally started thinking about the idea of designing a hypothetical language of my own and what form it would take. One area that I was keen to address is OO’s interfaces and inheritance. It’s a topic I’ve had many heated debates with various people over the past couple of years and so it seemed a natural place for me to start. As I was trying to work out how best to express my ideas, Microsoft launched TypeScript. It implements what I feel interfaces should have been all along and even gave me an “official” name for the technique: structural types. Continue reading “Structural typing, or did OO get interfaces wrong?”

Porting Ash to C# – Initial steps

At October’s Try { Harder } conference this year, Richard Lord – author of the entity framework, Ash – gave a great talk on entity frameworks. His talk confirmed something I’d been thinking recently, namely that the use of entity frameworks does not need to be limited to games. I’d recently worked on a domain-specific file crawler and processing application that adopted a timed loop to check for new files, progress in processing those files and updating the user on progress. Even this application would have benefited from using an entity system framework to control the interaction of its various parts. So after a quick chat with Richard to check the practicalities of my ideas, I decided to port Ash to C#. Continue reading “Porting Ash to C# — Initial steps”

NCrunch: or how to ruin a product with greedy pricing

Update: 19/02/2016
This is a historic post, which I felt needed updating to reflect my current position.

Whilst I still feel that NCrunch is expensive, I feel that price now needs to be put into context. In the three years since writing this, I’m been waiting for an alternative to appear, at a more reasonable cost. The obvious candidate would be JetBrain’s dotCover. That latter product has improved greatly over the last couple of years, and is much cheaper (ReSharper Ultimate, which includes ReSharper, dotCover and other tools costs $957 over three years, versus $577 for just NCrunch over the same period). However, dotCover still doesn’t run your unit tests in the background as you type. It only runs on a build.

Because of this, and despite its high price, I now both have a licence of NCrunch for myself and have budgeted for buying licences for the rest of my team during 2016. It’s expensive, but I’ve reluctantly concluded it’s a justified expense.

Original article
Around a year ago, I restarted developing using C#. I’d used it a few years previously, but hadn’t really looked at it for more than four years. One of the big changes I noticed was with free libraries and tools. When of the things that used to frustrate me with the .NET world was that it was affected by the Windows “charge for everything” mentality. In recent years though, that has changed and free, community-driven, tools and libraries are now plentiful.

Another big change has been the change in attitudes to testing. Four years ago, many developers didn’t know about test driven development (TDD), much less use it. This of course applied across the industry, not just with .NET. I discovered though that – thanks to Remco Mulder – C# had probably the best unit testing tool ever: NCrunch, which was free whilst in beta. Continue reading “NCrunch: or how to ruin a product with greedy pricing”

Field = Attribute = Property = Getter = Method = Member. WTF?

When I started learning about Object Orientated (OO) programming some 15 years ago, I was taught a set of terms to describe aspects of OO: class, object, method and field. In recent years, I’ve added one more term to the list: property. Whilst in my own mind, these terms have clear meaning, such meaning is not universal. Continue reading “Field = Attribute = Property = Getter = Method = Member. WTF?”

Is it time to retire Java?

DukeYesterday, the boss and I took a trip up to London for Sun’s UK Developer Update event at the Royal Geographical Society. There was a “keynote” by James Gosling, followed by presentations on JavaFX, Java EE 6 and details of what is likely to be in Java SE 7.

Now I should make it clear that until recently, I regarded myself as a C# and ActionScript programmer. I’m new to Java. This isn’t strictly true, as I used Java back in its Java 1.1 days, but its changed so much since those days (and I’d forgotten most of it anyway), that in practice I’m a Java newbie. As a result, I naturally judge Java against C# (and to a far lesser extent, against ActionScript).

C# owes its existence to Java. Languages prior to Java may have had garbage collection, reference types rather than pointers, bytecodes, just-in-time compilation etc, but Java bought these technologies into the mainstream. As it came after Java, C# was able to adopt all the good points of Java, and scrap the bad stuff (the getter and setter mess of Java is replaced with elegant properties for example). Whether it did this successfully or not is a matter of opinion of course. From my point of therefore, Java automatically deserves respect, but it doesn’t deserve automatic authority. People grow old and wise, but also grow set in their ways. Programming languages appear to do the same.

Despite its seniority, Java has some clear advantages over C#. Breaking to labels is a glaring omission in C#, which Java has. C# requires the use of the evil-incarnate “goto” to simulate breaking to labels. Also the XML mess that is documentation comments in C# is pure farce compared with the simple elegance of Javadoc. Java has a whole raft of deficiencies though, and the two biggest ones are the lack of anonymous functions (let alone closures) and the lack of properties. Both have been proposed for Java 7, but – according to Sun’s presentation yesterday – neither will now appear. On a lesser note, Java 7 will not support operator overloading either, so string comparisons will remain using the grossly messy .equals() method to compare string value. This is a minor issue in comparison with properties and closures.

Why are anonymous functions/ closures and properties such a big deal? Both can be worked around in Java. Properties are after all just a neater way of doing getters and setters and people have come up with bodge simulations of delegates for Java. The big deal is that these are basic features of modern languages. Even the somewhat “noddy” scripting language, ActionScript, manages to implement both. Every other JVM-based language that I know of – JRuby, Jython, Groovy and Scala – all support closures.

Java is old and is becoming set in its ways. Language developers always run into problems with balancing feature advancements with avoiding breaking legacy code and Java is no exception. Perhaps we need to accept that closures and properties will never come to Java as it is just too difficult to implement both neatly, without breaking backward compatibility in too big a way. If this is the case, then perhaps Java 7 should be the last version of Java and it ought to be retired and replaced with a younger, more adaptable language.Whether the growth in alternative JVM languages is a sign that people are already moving on from Java to newer languages is difficult to judge. JRuby, Jython, Groovy and Scala are all dynamic languages. Dynamic languages have seen a general resurgence in popularity recently. What is needed though is a static language replacement to Java. One that can seamlessly interact with legacy Java code, whilst supporting modern programming principles such as closures, operator overloading, properties etc, along with support for dynamic types (without being inherently dynamic), functional language principals such as currying and lambda expressions.

The more astute of you may spot where I’m heading here. Just as C# was born of Java, so perhaps we need a new version of Java, born of C#. Being a English tea addict, who is pretty indifferent to coffee, I propose (not very seriously) that we call it Lapsang. C# itself is starting to get old, and many of the new features – such as extension methods – have been implemented in an inelegant manner to avoid the backward compatibility issues that new keywords bring. So just as C# took Java’s good bits and added more of its own, Lapsang could take C#’s good bits, add a few new bits of its own (build concurrency into the core of the language for example) and give the JVM another 10+ years of life.

Java proberly is a dying language and it risks taking the JVM with it. If Sun (or IBM perhaps, if they buy Sun) bite the bullet and retire it as the prime JVM language, then there is no reason why the JVM cannot thrive and grow for many more years.