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: fluffy_dong@dsuper.net Subject: Re: scope and/or parameters (beginner) Date: 1999/04/15 Message-ID: <37155f01.1945002895@news.dsuper.net>#1/1 X-Deja-AN: 466578710 Content-Transfer-Encoding: 7bit References: <37064309.889106243@news.dsuper.net> <37084459.8616007@rocketmail.com> <370b0c99.1137352783@news.dsuper.net> Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.dsuper.net X-Trace: delphi.dsuper.net 924148462 2127 209.205.4.61 (15 Apr 1999 03:54:22 GMT) Organization: Delphi SuperNet Inc. Mime-Version: 1.0 NNTP-Posting-Date: 15 Apr 1999 03:54:22 GMT Newsgroups: comp.lang.ada Date: 1999-04-15T03:54:22+00:00 List-Id: On Tue, 13 Apr 1999 18:10:08 GMT, Robert A Duff wrote: >fluffy_doo@dsuper.net writes: > >> It looks like I am forced to declare a *new variable* in One_Procedure >> to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;), >> and then send modif_Var_2 in Internal_Procedure to be modified and >> brought back via its "IN OUT" parameter. > >That's right. > >The rule in some other languages (eg Pascal and C) is different -- in >those languages, a parameter acts just like a local variable, so you can >modify it, and it doesn't affect the caller's copy. That's error prone, >which is why in Ada an 'in' mode parameter acts like a local *constant*. > >- Bob What I'm surprised about is not about a passage through a single sub-program, but through two (2) of them in line, two levels down. I would have expected the IN parameter to protect the value against modification only for the sub-program from which it was first passed but not for the second one. As it stands, if a variable is passed down several sub-programs, it must keep the same passage mode throughout the entire line. I wonder why they made it this way. It would have seemed logical to make it so that an IN passage from A to B (only when B is declared INSIDE A) could have allowed an IN OUT of the same variable from B to C (C being inside B) to modify the value IN B BUT NOT IN A. This would have avoided the additional variable needed but would have still protected the variable's integrity in A. There would be no danger in inadvertantly affecting it via another sub-program declared outside of A because both B and C are declared inside A, and therefore not visible outside of it. One significant change it would have made would have been that formal parameters would behave differently depending on weather or not a sub-program is declared inside another or not, which I believe is not the case now (in today's real world of Ada). I have a feeling there is a good reason, a more specific one, why it is the way it is. If it's not too complicated to explain, maybe someone can try to tell me. Marc -- What I really am is "fluffy", no "_dong", no "_puff", no "_woo", no nothing, just plain fluffy.