3 ms·
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 starte
by danieldk 14y ago
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.
- nikolavp 14y agoWell 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
- delinka 14y agoChanging 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.