> > 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.
That might be your point of view. To me, the library designer is the one that has done the homework and should know better how to simplify things for others not a God. No one uses a high level library if implementing the low-level your self is easier. Libraries provide functionality that allow the application programmer to concentrate in what he is being paid for, making the application. An application programmer will have to define what the correct interface for the application is (for example, what UI to provide). There will be users that will say, I wish this application had a way of doing this, but unless they were technically savy and wanted to spend the necessary time to understand how the application works, they would not write the feature themselves; they will request that feature to the programmer. > 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. Those are called defects or "bugs". When I find a bug in a library or an application, I submit a bug report. I might have to work around it for a little bit, but I don't just work around it and call it goods. Library designers are normal programmers that work under a set of requirements like any other programmer (application programmers included), but when I find a bug in an application, I report it and try to work around it until it gets fixed; I don't hack the application or re-write my own just because a found a bug. > > 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). You see it as an intelligence challenge, where I see it as making things easier for everybody. Thanks, - Isaac. -- http://mail.python.org/mailman/listinfo/python-list
