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

Re: Why would anyone want opacity?



It appears that Bill Rozas and I actually hold similar attitudes
toward opacity, but express them in different ways.

I like to provide abstraction-breaking facilities, but to warn
that they are not guaranteed to provide any useful information.
An abstraction-breaking facility that may sometimes report that
it has nothing to report is good enough for heuristic purposes
such as pretty-printing and debugging.

In my implementations the quality of information provided by
abstraction-breaking facilities tends to depend upon various
compiler switches such as the optimization level and
debuggability switches.  It sounds like the same is true of
Rozas's implementations.  So what are we arguing about?

Could we perhaps finesse the opacity conflict by agreeing to
agree on interfaces for abstraction-breaking, but also to
agree that the reliability of the abstraction-breaking
operations will be a quality-of-implementation issue?

This would allow portable code to use abstraction-breaking
facilities, but not to depend upon them.

For precedent I would point to several flaky, partially
implementation-dependent things like RANDOM and EQ? that are
already in the language.

Will