5 ms·
> and adding a parameter is tightening the contract If a function took 3 parameters, and I've added another optional 4th one, how is that a tightening? All old
by nlitened 3y ago
> and adding a parameter is tightening the contract
If a function took 3 parameters, and I've added another optional 4th one, how is that a tightening? All old callers are still using 3 parameters, their contract has not been broken.
Of course, adding a required 4th parameter is an incompatible change, if you meant that. I wouldn't call it strictly tightening though, since it's incompatible both ways. But yeah, excuse me for being vague, I meant adding optional parameters.
Similarly, adding a field to a struct which the caller does not have to initialize or mention at all, is, in my opinion, also not a breaking change and does not tighten. Since all callers don't need to change their code or semantics.
- gavinhoward 3y agoI thought you meant an extra required parameter. Adding an optional one should not be a breaking change, and I have an idea or two of how to do it without breaking callers, even in a static language. Adding a field to a struct should still be a breaking change because that field could be used. If the caller does not initialize it, you might have a bug. If you're taking about Clojure maps, and not structs, that's completely different. But Clojure maps are open. Structs are closed. Adding something to a closed thing is a breaking change. Why? Because of what I said above: the new thing needs to exist. Rich Hickey calls this "place-oriented programming," and he hates it for that reason. He's not entirely wrong either because yes, it can easily cause breaking changes. But when you add something to an open thing like Clojure maps, that should not be a breaking change, and having implemented something like Clojure maps in C, I can tell you that it is not breaking, even in C.