3 ms·
Because implementation details are not an interface. Say that, for example, in the future the module code evolves and `y` becomes cached or lazy loaded. Then
by rectang 2y ago
Because implementation details are not an interface. Say that, for example, in the future the module code evolves and `y` becomes cached or lazy loaded. Then your external code reaching in and setting `y` to -42 directly may no longer have the effect that it did when you wrote your "monkey patch".
https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls
- Zambyte 2y agoThey are an interface, just clearly not the intended interface in this case. In the tower of abstraction, it is simply a lower level of abstraction than the public interface. It's important to speak at the appropriate level of abstraction for the problem at hand, and I believe library writers may not perfectly forsee the appropriate level of abstraction for everyone who uses the library.
- rectang 2y agoFor debugging, accessing private innards is fine because the version doesn't change before you're done. For long-lasting features, you can perform a risk-based analysis as to the likely stability of the implementation details you're accessing. But as a general rule: as a library author I deeply resent people who cause ME to get blamed when I change an implementation detail and their fragile code breaks when my library gets upgraded. https://xkcd.com/1172/ https://xkcd.com/1172/ > This update broke my workflow! My control key is hard to reach, so I hold spacebar instead, and I configured Emacs to interpret a rapid temperature rise as "control".