Re: Collective response to := messages

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <10963@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
@ By implementing your ADT as a limited
@ type, you deny the user of the ADT the ability to assign to variables and
@ in-out and out mode parameters of the type.  The only way to assign
# to such a parameter or variable is to pass it to a subprogram that is
# part of the implementation of the ADT.  That subprogram can then reclaim
# the storage refernced by the access value if it decides to give the parameter
# a new value.  

   Sure, except for the circumvention of the provided ASSIGN routine which
   occurs every time the ADT is passed as an "in" or "out" parameter.

   There is no way to deny the user this particular method of circumventing
   your assignment routine, or even to have the compiler warn the user
   that a limited private ADT cannot be relied upon as a value parameter.
   
> |     When what is being passed is known to the user as an access value,
> |     this is precisely what the programmer expects.  When what is being
$ |     passed is known to the user as an ADT, this sort of behavior is
$ |     totally counterintuitive.  It violates the abstraction.
$ 
$ Right.  So as I said above, define the ADT as limited private, so that
% you (as the implementor of the ADT) can have complete control over the
% use of the ADT.  That way the user of the ADT won't be able to violate the
% abstraction.

    Except by way of the parameter passing mechanism.