Re: "access constant" discriminant

["Randy Brukardt" <randy@rrsoftware.com>]

Matthew Heaney wrote in message
<1ec946d1.0302241111.3e816bb@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<v5d1sfo9ib2df9@corp.supernews.com>...
>> 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.