Re: Issue with GNAT GPL 2009 and GtkAda

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:u7txi934iaog$.gw40yhq8811x.dlg@40tude.net...
> On Fri, 26 Jun 2009 16:38:45 -0500, Randy Brukardt wrote:
...
>> We're also planning on adding a way to force by-reference parameter 
>> passing.
>> The motivating use is for the containers, but I'm sure it will find other
>> uses as well.
>
> This makes no sense to me. It is another mistake of making after C++. 
> There
> is no reason why by-reference must be enforced anywhere if not required by
> the type.

If you need "return by-reference" (however that is described), you need to 
pass the objects involved by-reference.

>> As far as the use of class-wide components, I think that would be easily
>> fixed by just allowing them.
>
> That would make objects non-contiguous. It is not obvious to me how that
> will work with streams and pools. I prefer a more transparent model when
> all components of a constrained object are constrained.

Well, Ada has always allowed non-continguous objects. There is no problem 
with streams: the stream attributes take care of any non-contiguous parts. 
As for pools, multiple calls to Allocate are allowed; again there is no 
requirement that the objects are contiguous. (That's been confirmed by 
AI05-0107-1, but it has always been true for Ada 95; there are plenty of 
AARM notes making that clear).

>> That would reduce the need to use access types some more. (But it can 
>> never
>> be completely eliminated; sometimes you really do need reference 
>> semantics,
>> especially for returns.)
>
> No, this is the mental trap. If something requires by-reference semantics
> that is not a return. Considering containers:
>
>   A (I) := X;
>
> It is a semantic mistake to treat A (I) as a function "returning"
> something. This can only lead to introducing more and more strange
> constructs like limited aggregates, return statements and other mess.
>
>   A (I) := X;
>
> must be treated as a syntax sugar for a procedure call
>
>   Put (A, I, X);

That works for full object assignment, but not in any sane way for in-place 
component updating. And full object assignment really doesn't need any 
special syntax (Replace_Element works just fine); the problem is when you 
need to update a single element of a container which is itself an element. 
It doesn't make sense to try to think of these sorts of operations as a 
single procedure.

                                    Randy.