Calling private base methods
isaac.rodriguez at comcast.net
Wed Apr 18 15:17:25 CEST 2007
> 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.
More information about the Python-list