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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1a88c4d509f6381 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: scope and/or parameters (beginner) Date: 1999/04/22 Message-ID: #1/1 X-Deja-AN: 469652059 Sender: bobduff@world.std.com (Robert A Duff) References: <37064309.889106243@news.dsuper.net> <37084459.8616007@rocketmail.com> <370b0c99.1137352783@news.dsuper.net> <37155f01.1945002895@news.dsuper.net> <7f52vj$n90$1@nnrp1.dejanews.com> <7f59oi$tse$1@nnrp1.dejanews.com> <371c4201.2003123297@news.dsuper.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-04-22T00:00:00+00:00 List-Id: fluffy_dong@dsuper.net writes: > I know that and I am curious as to why the people who designed Ada > made it this way, as opposed to the way that I described. If there is > no OUT then it would/should not matter what is done to the value > passed because it's not coming back. It would/should be treated as an > idependent copy of the variable passed. I know that is not the way it > works. Why not? (Don't answer. It's been answered below.) Even if all parameters were always passed by copy, the language designers would *still* have made 'in' parameters constant inside the called procedure. Suppose I wanted an 'in out' parameter, but I forgot to say 'in out'. The Ada rule saves me, because when I assign the new value to the parameter, I get a compilation error. Note that it's irrelevant whether the formal parameter is assigned by a direct assignment statement, or by calling another procedure which in turn has an 'in out' parameter. (Constant means constant, and, like Robert, I'm surprised that you would think passing it to another procedure would somehow turn that off.) Furthermore, constants generally make the code more readable, because if you know something is constant, you don't have to worry about it changing. That's true of local variables, and it's just as true of formal parameters. So of course formal parameters should default to being constant. (If I had designed the language, I would have done the same for local variables -- "X: Integer := 10;" would declare a constant, and "X: var Integer := 10;" would declare a variable.) And furthermore, the need to modify a parameter as a temp inside the procedure is rare -- if you need to do that, it's no big deal to declare a local variable and initialize it to the value of the parameter. And doing that makes it clear what's going on. - Bob -- Change robert to bob to get my real email address. Sorry.