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,799e6e37c90ca633 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Future Ada language revisions? Date: 1998/09/29 Message-ID: <6uqjh3$nbg@top.mitre.org>#1/1 X-Deja-AN: 395955437 References: <6um7on$db5$1@nnrp1.dejanews.com> <6uo71n$cr1$1@nnrp1.dejanews.com> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1998-09-29T00:00:00+00:00 List-Id: On the topic of IN OUT parameters for Ada functions: > We all lack perspective, and I probably lack more than most. However, when > I find myself using access parameters (and then aliased variables :-) to > work around this restriction, I'm forced to ask myself if the cure isn't > worse than the disease (side effecting functions). Using pointers and the Ada ALIASED keyword is only one way to alias variables. However, IN OUT parameters have the same coupling effect (to alias the variables through the parameter passing interface). The verb to alias means to permit changes in one variable to effect the value of another. Aliasing of any kind (including homonyms) encourages programmers to insert bugs in their code and then provides a path in the variable name space through which those bugs can propogate to other parts of the code. We should therefore become more aware of what language features cause aliasing to occur in address space or in name space, because of the software maintenance implications of this aliasing (that is, because aliasing provides bug propogation paths). To become more aware, here is a list of the Ada constructs (other than ALIASED) which provide a form of aliasing: overloaded variables such as RENAMES or equivalences or commons homonyms such as overloaded enumeration elements or array elements polymorphism or objects with changeable discriminants or tags external objects shared with other languages (e.g. pragma INTERFACE) parameters passed by reference (such as IN OUT) unchecked_conversion pointers or access type variables forcing the use of access variables to get things off the stack non-limited-private types re-use of variables for multiple assignments use of protocols like temporary variables or intermediate files non-limited-private-types Mike Brenner mikeb@mitre.org