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
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!rex!wuarchive!emory!gatech!mcnc!uvaarpa!software.software.org!smithd
From: smithd@software.org (Doug Smith)
Newsgroups: comp.lang.ada
Subject: Re: Reference vs. copy semantics in passing parameters
Summary: ADTs use limited private to proved control of parameter modes.
Keywords: ADT private
Message-ID: <1991Feb18.184145.1911@software.org>
Date: 18 Feb 91 18:41:45 GMT
References: <jls.666659373@yoda> <2742@sparko.gwu.edu> <2635@enea.se>
Sender: usenet@software.org (Usenet News/Mail Support)
Organization: spd
List-Id: <comp.lang.ada>

In article <2635@enea.se> sommar@enea.se (Erland Sommarskog) writes:
> Also sprach Micheal Feldman (mfeldman@seas.gwu.edu):
> >Jim Showalter (jls@yoda.Rational.COM) writes:
> >>In C++, you can declare not only the pointer constant but the pointed
> >>to construct constant as well. This allows passing by reference in a
> >>read-only manner, which is NOT possible in Ada at present.
> >
> >Well now I'm curious. Given that only scalars and small structures are
> >usually passed by copy, why would you want to guarantee reference
> >passing for read-only parameters in such a kludgy way? Ada provides you
> >with everything you need:
> 
> Don't get confused by terminology. Forget about passing mechanisms.
> Remember data abstraction.
> 
More specifically, notice how an ADT can be specified to control the
ambiguity of parameter modes for pointers to complex data structures.
Although a particular implementation of linked list might always
initialize a header record, then never need to change it during
Prepends, Appends, etc., IN OUT can enforce the intent of the
operations.  For example:

    package Linked_Integer_Operations is
        type Lists is limited private;

        procedure Append (List    : in out Lists;
                          Element : in     Integer);

    private
        ... Declare Lists as an initialized record whose value
            doesn't have to change during the Append operation.
    end;

Now the application engineer cannot accidently change a list that he
did not originally intend to change:

    procedure Reorder_List (New_List : in out Lists;
                            Old_List : in     Lists) is
    begin
        Append (Old_List, 0); -- will not compile !!!
    end;

    --    RM 6.4.1(3): actual must be a variable name or a conversion
    --    RM 6.2(3): assignment to an IN parameter not allowed

No matter how arrogant I become about my own programming skills, this
kind of compile time checking has saved me many headaches!