Re: Why would anyone want opacity?

["ozan s. yigit" <oz@nexus.yorku.ca>]

> |   Date: Wed, 8 May 1996 13:55:45 -0400
> |   From: Mitchell Wand <wand@ccs.neu.edu>
> |   Cc: will@ccs.neu.edu, rrrs-authors@martigny.ai.mit.edu
> 
> |   The solution that was arrived at in the 70's was the concept of
> |   information hiding and abstract data types.  The point of this was
> |   that it is insufficient to merely decree, as Jeff suggests that
> 
> |   ...
> 
> |   The arguments in favor of strong abstraction resemble in many ways
> |   the arguments in favor of strong static typing, and the objections
> |   to strong abstraction resemble those against static typic.  This
> |   is not a coincidence: static typing is one way of building certain
> |   kinds of abstraction boundary.
> |
> |   For a good short discussion of information hiding, see 
> |
> |   Steve McConnell, "Missing in Action:  Information Hiding", IEEE Software,
> |   March 1996, p 128.
> 
> As Jeff has arguled, your example does not argue for opacity.  It
> argues for disjointness of new types.
> 
> Disjointness eliminates the accidental use of the concrete representation.
> 
> Your position (not justified by your examples) implies that such
> access should be disallowed (rather than strongly discouraged and
> unlikely to happen accidentally).  However, as we've been discussing
> for a while, this also disallows the existence and creation of generic
> a-posteriori tools.

in the "..." part, he said:

| 1.  It would be desirable for the language to detect violations of an
| abstraction boundary.  This may happen prior to execution, as in CLU, the ML
| module system, etc., or at run-time in a dynamically typed language.
| 
| Note that I am _not_ presupposing what should happen when such a violation is
| detected.  The system might refuse to continue, issue a warning, raise an
| exception, check some kind of privileges or passkeys before proceeding, etc.
| But a manager (instructor, ADT implementor, etc) should be given some tools to
| protect his or her abstractions.

how did this become a position that implies "such access should be
disallowed (rather than strongly discouraged and unlikely to happen
accidentally)" all of a sudden?

is it impossible to build a language which can switch between
detecting abstraction violations, warns and allows them [for the
purpose of constructing these important "generic" tools] and detecting
such violation and disallows them? i think that is what mitch was
saying. have i read him too generously? :-|

oz