private variables/methods

[Michael Chermside]

gabor writes:
> in java/c++ i can make a method private, this way unaccessible for the outside
> world. i think it helps a lot to make for example a library more robust.
> 
> i know that there is some kind of notation to make a method/field private,
> but one can still overwrite it's value.
> 
> what's the reason for this?
> 
> i'l mostly interested in the design reasons.

First of all, I wonder WHY you think that it helps a lot to make (for
example) a library more robust. This is a serious question... because
it's not so obvious that it's true.

Suppose it's NOT true... suppose that having language-enforced access
limitations (as opposed to enforcing by convention) DOESN'T actually
make libraries more robust. Well, then, most of the time it would make
no difference whether your language had "private" declarations...
there would be a little more typing needed to use them, but the effort
might pay for itself in increased explicitness. HOWEVER, once in a
while, I have found that I have to use a library which doesn't quite
do what I want. Perhaps I have a slightly different use than the
original author had considered, or perhaps the original code is
buggy. In these rare cases, not having a language-enforced access
restrictions is USEFUL because I can work around the bug.

One design reason for NOT including language-enforced access
restrictions in Python is (IMHO) to allow the programmer the freedom
to make this kind of change when she wants to (realizing that by doing
so she is foregoing all warranty and incurring the risk of breaking
the library). A second (probably more significant) reason is because
NOT having it makes the object model quite simple... notice how in
Java and C++ make distinctions between methods and attributes, between
calling something from within the same class or file and calling it
from "outside". They require the invention of "friend" or "package"
access -- lots of complication needed just to support language-
enforced access restrictions. And balanced against these is the
increased library robustness that you (and others... you are not
alone!) say comes with the private declarations.

So you can see, this question of whether the increased robustness is
real is a VERY important question. Here's my take on the matter
(see also http://byandlarge.net/scuttlebutt/archives/000042.html):

There are two reasons that "true" (language-enforced, not
convention-enforced) privacy might be useful:

  (1) Mistake prevention -- avoiding accidental manipulation of
         bits intended for internal use only.
  (2) Enforcing coding standards -- for example, libraries should
         only be accessed via certain access points.
  (3) Preventing API publication -- so you can release a library
         but later change some internals without breaking any
         user's programs.
  (4) Security -- protecting from coders with malicious intent.

All of these are valid reasons for wanting to distinguish between
private and public interfaces. But if you take a "we're all grownups
here" attitude toward your fellow programmers (as Python does), 
then a simple convention (like leading-underscore-means-private)
will suffice for cases (1), (2) and (3). Sure, a few programmers will
decide to mangle your library's internals, but they do so at their
own risk!

Reason (4), on the other hand, can never be satisfied by a convention.
On the other hand, it is ALSO not satisfied by lots of existing
languages, and they manage to get along just fine! C++, for instance,
has several work-arounds that a malicious coder could use (the
simplest being to use "#define private public" before importing a
header file). As a result, the language CANNOT provide security
guarantees for running untrustworthy code. (Java or C# are much better
in this regard... they offer a feature that Python simply lacks.)

Of course, it might be that people are so lax about following
conventions that they're simply not very helpful. Perhaps in REAL life,
people just code willy-nilly and ignore any conventions not enforced
by the compiler. I've even seen shops which were like that. But it is
my experience that very few programmers behave this way, and that those
that do tend to have a net negative effect on projects. I've never
had a problem with a library because it didn't enforce access strictly
enough. I HAVE had cases where a library enforced access TOO strictly
(particularly trying to call const-aware C++ librarys from non-const-
using C++ code). I have also broken libraries by mis-using them, but
in such cases I had only myself to blame. And I've also SAVED libraries
by "misusing" or patching them in some manner.

What is YOUR experience on the matter? Can anyone here recount a time
when they had a problem with a library (or other code) in any language
because it DIDN'T enforce access strictly enough?

-- Michael Chermside