4 ms·

Works - yes. Works forever - probably not by which time you're in a world of pain. Your accessors are part of the class's immutable contract with the outside wo

by meaty 14y ago

Works - yes. Works forever - probably not by which time you're in a world of pain. Your accessors are part of the class's immutable contract with the outside world. When you couple the class internals to the contract, hacks will ensue en masse and your little party will fall flat on its face. It's fine for trivial stuff, but if you work with others, this will cause uber amounts of pain.

csense 14y ago
> if you work with others, this will cause uber amounts of pain. If this is true, why is it that there are plenty of large and successful frameworks and libraries written in Python? > hacks will ensue en masse Having downstream projects that use it is a sign of health for a library. If they're using the library in ways its creator never envisioned, so much the better for everyone. That's innovation. More than once, I've had to make a choice between partially re-implementing part of a popular Java library's functionality, or shipping my own fork with all the maintenance burden that entails, because in the official version a field I want to access is private, or a class I want to subclass is final.
Jare 14y ago
No, hacks do not necessarily follow lack of privacy. Over time, I have found that people tend to hack when: 1 - They can't do something 'the right way' because the contract won't let them. 2 - They don't know how to do something 'the right way' because the contract is insufficiently documented (or worse, outdated). 3 - They prefer 'the first way' to 'the right way' (in a rush, not give a damn, etc). To avoid 1) you need to have created an absolutely rock solid design that covers all use cases. To avoid 2), your documentation must be excellent. To avoid 3), there must be 'only one way'. Unless you comply with all of the above, and can also prevent the ability to copy& paste / duplicate your code, you perfectly hidden internals will not save your project from someone who wants to write dirty code. In fact, hidden internals only really help with 3) there. But, hey, they may not prevent all of it, but at least they will help reduce it, right? Maybe not. In practice, hen programmers don't have the mental safety net of hidden internals, my perception is that they tend to produce simpler designs, with lower amount of state and lower amount of dependencies among pieces of that state. Which in turn tend to improve the situation against 1,2 and 3 above.

by meaty 14y ago

csense 14y ago

> if you work with others, this will cause uber amounts of pain. If this is true, why is it that there are plenty of large and successful frameworks and libraries written in Python? > hacks will ensue en masse Having downstream projects that use it is a sign of health for a library. If they're using the library in ways its creator never envisioned, so much the better for everyone. That's innovation. More than once, I've had to make a choice between partially re-implementing part of a popular Java library's functionality, or shipping my own fork with all the maintenance burden that entails, because in the official version a field I want to access is private, or a class I want to subclass is final.

Jare 14y ago

No, hacks do not necessarily follow lack of privacy. Over time, I have found that people tend to hack when: 1 - They can't do something 'the right way' because the contract won't let them. 2 - They don't know how to do something 'the right way' because the contract is insufficiently documented (or worse, outdated). 3 - They prefer 'the first way' to 'the right way' (in a rush, not give a damn, etc). To avoid 1) you need to have created an absolutely rock solid design that covers all use cases. To avoid 2), your documentation must be excellent. To avoid 3), there must be 'only one way'. Unless you comply with all of the above, and can also prevent the ability to copy& paste / duplicate your code, you perfectly hidden internals will not save your project from someone who wants to write dirty code. In fact, hidden internals only really help with 3) there. But, hey, they may not prevent all of it, but at least they will help reduce it, right? Maybe not. In practice, hen programmers don't have the mental safety net of hidden internals, my perception is that they tend to produce simpler designs, with lower amount of state and lower amount of dependencies among pieces of that state. Which in turn tend to improve the situation against 1,2 and 3 above.