Hot answers tagged

185

A major version upgrade literally means they intend to break things. You shouldn't upgrade to a new major version unless you're prepared to deal with it. Most build systems have a way to specify you're okay with automatic upgrades to minor versions, but not to major versions. APIs break for a number of reasons. In this case, I'm guessing it's because what ...


55

My point, and question, is: Why do library developers knowingly break existing code like this? Why not at least have it default to either true or false, whichever is the most reasonable? Because sometimes it's better to force someone to explicitly make a newly added choice, as opposed to making it for them and effectively having to guess. If my usual ...


12

Some good answers already, however, let me add my two cents from some real-world experience. More than often, though usually acting in good faith, some API designers are pretty ignorant what kind of casding effort such decisions might cause. They have probably a wrong idea about how much client code has to be fixed by such a change and how much ...


7

Consider when you'd break things yourself. Off the top of my head, I can think of a few reasons: You're updating the API to: Conform to a language convention Shift to a more applicable programming style (say, have a function return with partial application where it makes sense) You're refactoring some implementation, and that allows for a more effective ...


4

Your two examples are effectively equivalent – the PHP engine processes the entire file and interprets the outside HTML roughly as if it were a string that is printed out like in the second example. There is no extra overhead. And if there is any overhead, it is insignificant compared to actions like waiting for a database response, or negotiating an ...


2

There are two opposing goals involved here avoidance of arbitrary dependencies to some global state variables (which makes testing and reasoning about the code hard, especially when the code base grows) avoidance of having to write a lot of cumbersome, similar code which repeats passing the same parameter over and over again. Often, there is a compromise ...


2

Ultimately this comes down to the elusive and controversial goal of backwards compatibility. As a developer of application A, you would like to spend your time doing three things: adding features fixing bugs if you have done your job well, and there are no features to add or bugs to fix, bask in the glow of having written a long-term stable application that ...


2

One of the few things I remember from my CS undergraduate course - now 50 years ago - is David Wheeler's quote "compatibility means deliberately repeating other people's mistakes". Over time you learn that the original design was wrong. It can be wrong because it creates a security weakness, because it leads to poor performance, because it prevents ...


1

As someone who's authored dozens of libraries on Nuget and Github, I can tell you that backwards compatability is an important consideration. Despite some other answers here, I don't believe most libraries authors deliberately set out to break backwards compatibility. Indeed, it is often possible to add many new features and improve existing ones without ...


Only top voted, non community-wiki answers of a minimum length are eligible