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. Regards, Tony