Isaac Rodriguez <[EMAIL PROTECTED]> wrote: > > The fact that I had > > to resort to this trick is a big indication of course that genuinely > > private members (as opposed to a 'keep off' naming convention) are a bad > > idea in general. > > The fact that you had to resort to this trick is a big indication that > the library you were using is bad designed; it has nothing to do with > private members being a bad idea. You were using a library which
This is just like the airlines invariably concluding "human error" in just about every instance of an airplane crash or similar problem... Don Norman has some choice reflection about that issue from the point of view of a user-experience specialist, or, one could try Charles Perrow's classic "Normal Accidents" for more of a systems-level view from a sociologist's viewpoint. C++'s and Java's approaches are vitiated by an unspoken assumption that the library's designer is some kind of demigod, while the writer of code that uses the library is presumably still struggling with the challenge of opposable thumbs. In real life, the skills of the two people in question are likely to be much closer, and since designing libraries for use in all kinds of applications is a really hard task, it's likelier than the library designer will make an error in designing his or her library, rather than the application programmer in using that library. Purely-advisory encapsulation approaches, like Python's, even the odds. Actually, I'd argue that even double-leading-underscores are overkill more often than not (and single-leading-underscores the compromise that is generally prefereable). Alex -- http://mail.python.org/mailman/listinfo/python-list
