Hacker News Reader

Except when you want to change behavior in the future, e.g. adding a check to the getter or doing more than simply setting a value in the setter.

If you started out with getters/setters in the first place, you can do this without changing the API and ABI.

View on HN

Well if you are changing the behaviour of the getter or the setter then you are already changing the public API contract.

I would rather want a compile time error instead of a silently not changing value in a setter for example after a library upgrade

Changing the underlying implementation is not changing the API contract. The API makes no guarantees about where your arguments are shipped off to nor where the return value came from. It simply says "you give me X, Y, Z and I'll return you M" and that's it. This is the very reason for specified APIs: the underlying implementation changes (for caching, efficiency, new storage models, etc) and external code goes on its merry way doing what it did before-- running.

Reply on news.ycombinator.com