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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,50137bb64a119cfc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-24 13:15:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: "access constant" discriminant Date: Mon, 24 Feb 2003 15:17:37 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <_TO1a.14664$9y2.6601@nwrddc01.gnilink.net> <3CS1a.55972$2H6.1357@sccrnsc04> <3E4E9248.3E71D984@adaworks.com> <1ec946d1.0302201642.66eb93e5@posting.google.com> <1ec946d1.0302241111.3e816bb@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:34535 Date: 2003-02-24T15:17:37-06:00 List-Id: Matthew Heaney wrote in message <1ec946d1.0302241111.3e816bb@posting.google.com>... >"Randy Brukardt" wrote in message news:... >> Matthew Heaney wrote in message >> <1ec946d1.0302201642.66eb93e5@posting.google.com>... >> >> >Here we see the reason why we passed an access parameter: it's because >> >we're returning an access value that designates one of our own >> >components. >> >> >> That reason being only that Ada doesn't support 'in out' parameters on >> functions. If it did, >> >> fuction Persistence_View >> (Object : in out T) return Persistence_Class_Access is >> begin >> return Object.Persistence_View'Access; >> end; >> >> would work fine, and would be a lot easier to use as well. > >No -- this would be the wrong way to implement the multiple views >idiom. You really do want to make explicit the fact that the object >is being aliased. All tagged objects are aliased. (It's silly that you have to declare that for object declarations, and it is true otherwise by default, but that's just a glitch in the standard). So the fact that it's tagged makes it explicit. You don't need to introduce junk access types in order to do it. (Yes, both access parameters and access discriminants introduce new access types.) ... >Which makes it identical to how you'd say it in Ada95. So this is not >really an Ada issue. Never, ever use an explicit access in Ada95 if you can avoid it. Save explicit accesses for dynamic allocation. >> But that's not going to happen, so we're stuck with terrible workarounds >> like 'access' parameters. > >Access parameters have other uses besides getting around the lack of >inout mode for function parameters. For example, operations that >accept a user-defined type as an access parameter are primitive for >the type, and hence are inherited in a derivation. And an access >parameter means you don't have to say Op (O.all) everywhere. I realize that's true, but its a pointless distinction. "in out" and "access" have pretty much the same semantics inside the subprogram. Avoid explicit access types unless they are really needed. So 'O' probably won't be a pointer in the first place, and certainly you don't want to require that it is a pointer. I'd much rather say: Op (O.all) (especially as it makes it clear that you're doing a dereference and thus require a non-null pointer) than Op (O'Unchecked_Access) And the latter requires an explicit, junk 'aliased' declaration. (It's junk because all tagged types are effectively aliased anyway -- you just have to pass them to an operation to see that.) >However, we are in agreement that not having inout mode for functions >is a ridiculous restriction, since functions in Ada95 do modify their >arguments (the language just doesn't let you *say* that you do). Wow! We agree on something! :-) Unfortunately, no one is willing to vote to change this restriction (although no one seems to have a legitimate reason for keeping it, just a bunch of FUD). Sigh. Randy.