[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opacity considered harmful

This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.

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.