C, C++, OCaml, Eiffel, Ada, most assemblers, and the like have
facilities for "mandatory information hiding", in which some parts of
the program are not accessible to other parts of the program.
Textbooks and academic papers on such things often describe their
benefits in terms of security, with examples like bank-account objects
that must conserve funds in the face of malicious client code.

It's often useful to think about software robustness properties in
terms of robustness against malicious attacks, since if a malicious
attacker wouldn't be able to violate some robustness property, then no
neither can client code that is simply malfunctioning.  The benefit of
thinking in these terms is that it avoids the necessity to model the
possible malfunctions of the client code and their probabilities, a
cognitive task generally so difficult as to be infeasible a priori.

And there have been various systems that use language-level
information-hiding facilities to enforce security properties --- E is
the best-developed example, but Java has tried to do this as well.

However, though, it is not necessary to resort to arguments about
robustness in the face of partial failure or malicious attack to
justify the introduction of these mechanisms.  The benefit they have
given me from time to time is quite different.

It's well known that most of the time spent on programming is spent on
"maintenance", by which we mean modifying software somebody is already
using, usually to add new features; and that most of the time spent on
"maintenance" is spent understanding the existing code so as to be
able to make modifications that won't break other things and won't be
hard to understand again later.  Much of this activity consists of
understanding what parts of the code must be changed together, and how
they must be changed to ensure that the code continues working.

The advantage of mandatory information hiding is that this task
becomes simpler.  If I'm changing the semantics of a private method in
C++, I need only look within that method's class for calls to the
method; I don't need to look anywhere else.

I have occasionally wished for this feature in Perl on a 100 000-line

This understanding of facilities for mandatory information hiding
suggests some differences over the standard understanding:
- The facility is still important even when you don't have malicious
  code running in your process space, and even in languages like C++
  or Python where there is no really effective access control.
- The point of the facility is not to keep information from your team
  members, although indeed some of its earliest proponents thought it
  was.  Therefore, changing a method from private to public because
  you need access to it from somewhere else is not a sin.  (At least,
  not for this reason.)

Reply via email to