From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!ucbvax!ulysses!hector!dsr From: dsr@hector.UUCP (David S. Rosenblum) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <10963@ulysses.homer.nj.att.com> Date: 5 Dec 88 14:46:10 GMT References: <10960@ulysses.homer.nj.att.com> <3734@hubcap.UUCP> Sender: netnews@ulysses.homer.nj.att.com Reply-To: dsr@hector.UUCP (David S. Rosenblum) Organization: AT&T Bell Laboratories, Murray Hill, NJ List-Id: In article <3734@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes: | OK. Envision an ADT which just happens to be implemented as a pointer | to a descriptor, which probably has more pointers to the "value". Now | our ADT user wishes to transfer an ADT "out". The ADT user has no idea | how the ADT is implemented. Now when the procedure was invoked, let's | assume that the ADT supplied as an actual parameter had some value; | hence, the pointer which represents the "ADT type" is not null, and | in fact constitutes the only known method for accessing a substantial | amount of utilized memory. Our ADT user sends the value "out", and | Ada implements this by copying the value of a single pointer. The old | pointer value associated with the actual parameter is lost forever, | and all the stuff it pointed to is now garbage. The language already has a very nice feature to handle such situations. It's called the "limited type". 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. Geoff Mendal did a nice paper on the encapsulation of storage reclamation mechanisms inside user-defined ADTs in a paper he gave at a recent SIGAda (you can get a copy from him). | Anything which is passed as an "in" parameter should be treatable as | something which was passed in by value. Anything which is passed as | an "in out" parameter should be treatable as something which was passed | by reference. Anything which is passed as an "out" parameter should | be treated as the target of a pass by value in the "outward" direction. | | If nothing can be assumed about parameter passing behavior, then | parameter passing is just too vaguely defined, and needs to be clarified. You'll have to take this up with the Ada Language Maintenance Committee. The language designers, and many Ada programmers, believe it to be as clearly defined as it needs to be so that portable programs may be written. | 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. Back to work. ------------------------------------------------------------------- David Rosenblum UUCP: {ucbvax, decvax}!ulysses!dsr AT&T Bell Laboratories ARPA: dsr@ulysses.att.com 600 Mountain Ave. dsr%ulysses@att.arpa Murray Hill, NJ 07974-2070 (201) 582-2906 -------------------------------------------------------------------