Re: Reprise: 'in out' parameters for functions

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:c5gh0e$1ba02$3@ID-77047.news.uni-berlin.de...
> Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:c5b6pt$2pcs4d$2@ID-77047.news.uni-berlin.de...
> > ...
...
> > I don't see how this follows from (1) to (4), though. Each call is just
a
> > dispatching call to a single operation; there is no implementation
> > inheritance.
>
> Yes, but if I could have two dispatching parameters of same protected type
> (no MD involved) in a primitive operation, then a call to it should start
> two protected actions. Same with task entries, (4) should allow something
> like:
>
> task type Foo is ... end Foo;
> entry Double_Rendezvous (X, Y : in out Foo);
>    -- Declared after "end Foo";

This isn't allowed by AI-345; entries can only be declared inside a task
(with the current rules). An interface can have procedures that match
entries (and interface procedure calls can be used in select statements),
but there is no separate existence to entries.

You could declare a procedure like that

procedure Double_Rendezvous (X, Y : in out Foo);

but of course it doesn't have any special semantics.

...
> >> A call to such entry would start multiple protected actions (one per
each protected
> >> object parameter) and multiple rendezvous (one per each task object
> >> parameter). Could we agree that 1-4 is a damn *lot* of work?
> >
> > Not really. *Interfaces* is a lot of work, but presuming that we're
going
> > to have those anyway, adding protected and task support to them is not a
> > significant increment.
>
> I am glad to hear it from you, because of course, you know it better.

I should point out that not everyone agrees with my assessment here. But
it's not clear to me that everyone understands the implementation model for
these, so they may be trying a harder-than-necessary implementation
approach.

                  Randy.