Per Bothner wrote:
> Security is not the motivation for opacity.  Maintainability is the
> main motivation: If I don't expose the internals of my data structures
> to client programs, then I have a better chance of modifying those
> internals in a future version of my library without breaking those
> clients.

Yes, that's a nice idea, but in practice things don't work that way.
There are better ways of achieving a stable public API than simply
disallowing access to some structures.

I've found that documenting the API, or adopting some other non-coercive
means for communicating the difference between interface- and
implementation-related code, does a much better job of keeping things
clearly enough separated to allow internal reworking a greater chance of
working seamlessly with client code.

I've also found that neither coercive (sealed/opaque) nor non-coercive
(documentation) means for keeping interface and implementation separate
provide a *significantly* greater chance of seamless upgrades. Things
still break far more often than not when upgrading libraries. (Well, in
the Java world, anyway.)

It costs a lot to be put in a position where I have to either sit on my
hands and wait for the next release (if any) of a library I need, or
switch to some other similar library (if there is one).
Abstraction-breaking reflection, in some of these cases, is a lifesaver.

Regards,
  Tony