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,b47b15fda2aeb0b2
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Two ideas for the next Ada Standard
Date: 1996/09/03
Message-ID: <Dx5ywt.Jvn@world.std.com>#1/1
X-Deja-AN: 178219431
references: <50aao3$3r88@news-s01.ny.us.ibm.net>
 <322B5BB0.422E@joy.ericsson.se> <50gelc$2le@goanna.cs.rmit.edu.au>
 <322C40B1.534A@ehs.ericsson.se>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-09-03T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <322C40B1.534A@ehs.ericsson.se>,
Jonas Nygren  <ehsjony@ehs.ericsson.se> wrote:
>type X1A is access X;
>type X2A is access X;
>X1P : X1A;
>X2P : X2A;
>
>To use X1P and X2P together often requires conversions.

So don't do that.  ;-)  Just define one access type after each type, and
use a naming convention, and always use that particular type.

You *do* get "extra" type conversions, though, when using class-wide
types -- if T2 is derived from T1, then T1'Class covers T2'Class, but
the corresponding thing doesn't work for access-to-those-classwide-types.

>If you write code using tagged types you often want to use dynamically
>allocated objects and hence use access values in function/procedure
>calls. When one pass 'the object' as an access argument the 'object'
>will always have mode 'in out', it is not possible to pass the
>object with only 'in' mode. So if you want to provide functions
>or procedures which restricts the update of 'the object' then
>you have to provide an interface with a mix of 'access' and
>'in' modes with the following confusion for the user of the interaface
>who will need to use a mix of P1(XA) and P2(XA.all). It is very ugly
>and confusing to use such interfaces.

I suppose that's a valid criticism.  The reason there are no "access
constant" parameters is that we didn't think it was needed, which is not
usually a good language design principle -- the language should forbid
harmful things, but shouldn't forbid percieved-useless things,
especially since it's not always clear what will be useful to somebody.
I guess it depends on whether you think "access constant" params is an
additional feature, versus the lack of "access constant" params being an
additional restriction.

However, I don't think it's a big deal.  You can just use "in" and "in
out" all the time, and use ".all" at the call site.  Two annoying things
are: The syntax for ".all" is ugly -- I liked Pascal's "^".  And
functions can't have "in out" params.

You only need access parameters when the dispatching function wants to
store a pointer to the thing in some global data structure, which I
think is no common.  And when you have a function with side-effects,
which is also rare.  (Note that parameters of a tagged type are always
aliased, so you can do 'Access or 'Unchecked_Access, but the
accessibility rules make access parameters more friendly.)

And in any case, missing or extra ".all"'s and 'Accesses are caught at
compile time.

- Bob