Every public change is a breaking change

re: Every public change is a breaking change

Adam Ralph — Fri, 24 Aug 2012 11:12:37 GMT

@Tim Copenhaver, I can't help wondering what these two distinct "developer" and "architect" roles are?

re: Every public change is a breaking change

Joshua — Tue, 14 Feb 2012 00:08:24 GMT

There's a handful of places where reflection to access certain private members is so common that changing them qualifies as breaking.

re: Every public change is a breaking change

Staffan Eketorp — Mon, 16 Jan 2012 10:06:08 GMT

Sorry - I wrote @Tim - I meant @Brian

re: Every public change is a breaking change

Yelinna — Fri, 13 Jan 2012 17:21:15 GMT

The problem I see here is Overloading Abuse!

Too much Overloading is bad for your App

re: Every public change is a breaking change

Brian — Thu, 12 Jan 2012 14:11:12 GMT

@Staffan:

1. I really appreciate that when I upgraded my server from .Net 2.0 to .Net 4.0, I only had to fix a few things (aka, breaking changes) before my site would work. I would have been hesitant to update if I believed this would not be the case.

2. Breaking changes that are easy to fix automatically can usually be made in a way that prevents them from being breaking changes (ignoring edge cases like this one), and such automation will usually fail in the same places as the change is breaking.

3. If you're using a library you don't own, having it break is horrible.

re: Every public change is a breaking change

Gabe — Wed, 11 Jan 2012 16:24:15 GMT

I would like to add that I've had code break simply from the *creation* of a public class!

re: Every public change is a breaking change

tobi — Tue, 10 Jan 2012 18:01:01 GMT

The ultimate breaking change would be to flip a meaningless bit and break client code that checks the assemblies exact hash. I am sure this has happened.

re: Every public change is a breaking change

Tim Copenhaver — Tue, 10 Jan 2012 14:34:37 GMT

I agree that this probably isn't something most developers need to worry about, but it is absolutely something most architects should think about. In a perfect world, The unfortunate fact of the world is that people who consume library code don't want to have to update their code just because you changed something. Library architects have to go out of their way to prevent breaking changes.

Obviously the example here is a little contrived, but there are applications. For example, these problems are a lot more likely with fluent-style APIs due to the common method names. Architects should balance that risk with the potential improvement in usability before picking a pattern. Extension methods are another example - core, critical functionality should be placed directly on the class whenever possible to prevent accidental overrides by consumers. I'm sure there are other examples where these sorts of issues can drive important decisions in the real world. They shouldn't just be ignored.

re: Every public change is a breaking change

Staffan Eketorp — Tue, 10 Jan 2012 14:09:11 GMT

I believe a made a comment before but it seemed to disappear.

Howevver, it seems to me that the breaking changes tradeoff always comes up. In an agile world this just doesn't seem to fit my view of how things should be done. We promote constant refactoring and agile mehotds everywhere else. Isn't it time for us developers to change perspective? Instead of trying to provide non-breaking changes - shouldn't we deliver a tool that lets the consumer convert his code to the new specifications. Obviously this tool could be pedagogic, combine warnings presentations with errors etc. etc. We only need a good abstraction over C# code now! Oh wait...yeah Roslyn is on its way.

However, this will naturally require time and effort. You can't help but thinking that a programming language that includes a "transaction log" of the program would be beneficial, i.e. information on how methods have come and gone and changed name or so. But I know of no such language.

Opinions, Eric?

re: Every public change is a breaking change

Jeroen Mostert — Tue, 10 Jan 2012 10:23:26 GMT

You know, all these examples make me think overload resolution is just too clever for its own good -- these kinds of algorithms are more the kind you'd expect in the optimizing part, where cleverness abounds, not in the basic semantic part.

Clearly, the solution is to abolish overload resolution, assign every method an unambiguous canonical name (that's stable in the face of changes) and force the developer to specify this name on every call. Alternatively, make overload resolution unnecessary by forbidding overloads. Not sure how to handle generics in such a world -- abolishing them seems too harsh.

(Mandatory Internet disclaimer: the above is facetious, but slightly ha-ha-only-serious.)

There are languages that do not have overload resolution. A .NET language could, for instance, specify the unique metadata token associated with the method definition. But in a world without overload resolution, how would you do query comprehensions? -- Eric