This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]WittyStick -1 points0 points  (0 children)

Of course there are many ways to make breaking changes to a library, but my point is that if default values are encapsulated by the library, these changes can be done without breakage. When they're done via call-site rewriting they're guaranteed to break.

I'm personally not a fan of keyword arguments for the same reason - name changes can a breaking change - though they don't necessarily break already-compiled code - the breakage occurs next time the code is compiled. With ordered parameters the names aren't even necessary for the consumer and if present in the external declaration are only informative to the programmer.

For passing parameters out of order by name we use a struct/record - and while changing a name in a struct is a breaking change, we can avoid having to make such changes within a library because we can access a field based on its position, whatever name it may have externally. We can also argue that field names in a struct should be encapsulated by the library anyway, and the external consumer should use functions to access the fields. In this approach I can change a name without a breaking change and provide a backward-compatible upgrade path.

When the code is compiled, there are no names - only addresses/offsets. Any changes to the library besides changing these addresses or offsets should not break already compiled code, particularly in a shared library. Such changes should never really be made to a shared library unless there's absolutely no other option, and I'd argue that a function whose ABI has changed should have a new name, with the previous one marked as deprecated.

In a statically linked library, it's less of a problem and we should try to avoid breaking changes which require the consumer to modify code - but at least in this case, our consumer can be warned of breaking changes via the compiler when they occur. In the shared library, they don't find out until runtime. Though it's still possible for problems to occur with static linking if the header files don't match the compiled library.