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.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!cme!leake From: leake@cme.nbs.gov (Stephe Leake) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <778@marvin.cme.nbs.gov> Date: 7 Dec 88 17:15:26 GMT References: <10960@ulysses.homer.nj.att.com> <3734@hubcap.UUCP> Organization: National Institute of Standards & Technology, Gaithersburg, MD In-reply-to: billwolf@hubcap.clemson.edu's message of 4 Dec 88 23:27:17 GMT List-Id: In article <3734@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) 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. This is precisely the reason for limited private types; only functions provide by the ADT package may have out parameters of the limited type, so the ADT programmer can ensure correct behaviour, including garbage collection and copying. This is a much simpler solution than forcing parameter passing to use the ADT assignment operator. 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. The program should be independent of the choice of parameter passing implementation. (LRM 6.2 (7) says so). What can be assumed about parameter passing behaviour is precisely what the LRM says (mostly in 6.2,3,4); no more, and no less. If you want different semantics, use a limited type (and document the semantics in the package spec). > Second, an access value can be passed as a parameter, in which case the > language is concerned only with the access value during parameter passing, > NOT with the object designated by the access value. 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. Once again, this is why limited types are available. It is up to the ADT implementor to insure that abstraction violations are not possible. This is not always easy. Stephe Leake (301) 975-3431 leake@cme.nbs.gov National Institute of Standards and Technology (formerly National Bureau of Standards) Rm. B-124, Bldg. 220 Gaithersburg, MD 20899