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, MSGID_SHORT,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!ukma!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <3734@hubcap.UUCP> Date: 4 Dec 88 23:27:17 GMT References: <10960@ulysses.homer.nj.att.com> Sender: news@hubcap.UUCP Reply-To: wtwolfe@hubcap.clemson.edu List-Id: >From article <10960@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum): > |> They are not the least bit equivalent, for several reasons. The most > |> obvious reason is that an implementation is free to pass composite > |> parameters by reference, although no implementation can "assign by > |> reference". > | > | Sure, for "in out" mode. But for modes "in" and "out", failure to > | use the ADT's assignment procedure causes major problems: > | > | "out" mode: Programmer assigns the parameter a value, and the > | value is copied back to the actual parameter. > | Unfortunately, the portions of the actual parameter > | which were formerly accessible by pointers are now > | uncollectable garbage. > | > | "in" mode: Programmer assumes that this is a "pass by value" > | and makes modifications. Since ADT contains pointers, > | modification echoes through to the actual parameter. > | Programmer could also invoke DESTROY, blowing away > | major portions of the actual parameter. > > I'm terribly confused. Are we still talking about Ada? With this talk > about parameter passing invoking source-level assignment, I'm not so sure. > I'm not sure what your "out" mode comments refer to, but maybe you're > confusing what access values (pointers) can point to in Ada, or maybe you're > confusing how access values are passed as parameters in Ada--access values are > ALWAYS copied IN to their respective places in formal parameters, EVEN for > mode "out" formals. 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. > Your "in" mode comments are also vague. First of all, > "good" Ada programmers assume nothing about parameter passing behavior. 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. > 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. Bill Wolfe wtwolfe@hubcap.clemson.edu