Jim> This seems outdated. My impression, in part from time spent
Jim> working with the Python Labs guys, is that it is fine to have
Jim> public data sttributes even for non-"record" types. In fact, I
Jim> would argue that any time you would be tempted to provide
Jim> "getFoo()" and "setFoo(v)" for some "private attribute _foo", it
Jim> would be better to make it public. I certainly find "blah.foo" and
Jim> "blah.foo = v" to be much better than "blah.getFoo()" and
Jim> blah.setFoo(v)".
Presuming the foo attribute provides some element of the API that you are
willing to support forever. If it is just an implementation detail you
should use accessor methods or properties.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4