Adding functionality to a library, without touching the existing code should be safe for clients, shouldn’t it? Unfortunately not, adding another overload to a library can be a breaking change. It might work when the library is updated, but suddenly break when the client is recompiled – even though no code was changed. That’s nasty, isn’t it?

When working with Kentor.AuthServices I’ve had to think through versioning more in detail than I’ve done before. When is the right time to go to 1.0? What is the difference between going from 0.8.2 to 0.8.3 or 0.9.0? When researching I found that the answer to all versioning questions is Semantic Versioning.

A version is on the form Major.Minor.Patch.

• Major is increased if there are breaking changes. The other numbers are reset.
• Minor is increased if there is added functionality that is non breaking. The patch number is reset.
• Patch is increased for backwards compatible bug fixes.

The terms breaking changes and backwards compatibile are keys to the definitions, so to use semantic versioning requires keeping tight control of what changes are breaking and not. In most cases it is quite simple, but there are a few pitfalls that I’ll explore in this post.

The background to this post is that I listened to Scott Meyers’ NDC talk Effective Modern C++ and was reminded on how C++ programmes have to keep track of all kinds of nastiness in the language that might turn into hard to track-down bugs. C# is a lot easier in many ways, with way fewer pitfalls, but sometimes I think we make it to simple to ourselves. C++ developers are often quite good at the language details because they have to. Being a C# developer it is possible to survive for much longer without knowing those details, but being ignorant of them will eventually result in nasty bugs. That eventuality will probably not happen on a lazy Tuesday morning with a lot of time to fix it. It will happen a late Friday afternoon, right before the important production deployment scheduled for the weekend…

As C# developers I think that we should have a look at the C++ community and see what we can learn from them. So let’s dive into some code and see how we can break things.

• Continue Reading →

There’s more to this in JavaScript than I showed last time. Time for more details on methods, closures and the global object.

This is a direct continuation of the this in JavaScript vs C# post. If you haven’t already read it, I suggest that you read it before continuing here.

More on Methods

Last time I finished with a code example with a method that allowed me to receive payments and show my current cash level. In this post I’ll add the same function as a method to another object.

• Continue Reading →

Coming from C#/C++/Java, the usage of the this keyword in JavaScript is confusing. This is my attempt to explain it, in C# terms (with C# being very close to C++ and Java). I’ve thought of writing this post a long time, but it’s just now, when reading JavaScript: The Good Parts that I’ve finally understood it well enough myself to be able to explain it.

In C# (and C++ and Java) the this keyword is available inside any class method and refers to the current object used to invoke the method. When I first started writing JavaScript I assumed that it would be the same, but soon found out that I was wrong. this in JavaScript has a different behaviour.

JavaScript Objects

My first assumption was that inside a method the this keyword would refer to the current object. I was surprised when things didn’t behave as I expected, but it wasn’t this fault. It was my lack of understanding of JavaScript objects and methods. JavaScript is object oriented, but it is a prototypical object orientation which is not at all the same as the class-based object orientation in C#.

• Continue Reading →