Re: Interfaces and private types

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

"Philippe Tarroux" <philippe.tarroux@limsi.fr> wrote in message
news:fnmruc$ive$1@news2.u-psud.fr...
> Randy Brukardt wrote:
> > Specifically, it violates 7.3(7.3/2): "the partial view shall be a
> > descendant of an interface type (see 3.9.4) if and only if the full type
is
> > a descendant of the interface type."
> >
> > As written, this is illegal because type T does not have the interface
> > Int.
> As it is written the compiler i use doesn't mention any error and i
> interpreted this construct as legal because :
>
> 1/ the interface is synchronized thus allowing to derive concurrent or
> non concurrent types

Sure.

> 2/ The partial view is a descendant of the interface type

Sure.

> 3/ The full view precises that the partial view correspond to a
> concurrent type but hides this detail to the user

Sure.

> Writing, as you propose
>
> task type T is new Int with private;

That's not what I proposed. You have to repeat the interface name on the
full type declaration, and you did not write that in your original question.

package Test_Interfaces is

   type Int is synchronized interface;
   procedure Init (I : in out Int) is abstract;

   type T is new Int with private;

private
   --task type T is -- This is what you originally had, and it is illegal.
   type type T is new Int with -- This is legal, and presumably is what you
meant.
      entry Init;
   end T;
end Test_Interfaces;

I again refer you to 7.3(7.3/2) in the RM.

...
> > You could work around the bug with something like:
...
> But the overriding procedure Init needs to be redefined both as an entry
> of T and as a procedure. I assume that when i will be trying to call
> O.Init with O a type T task there will be a mistake due to the double
> definition.

You shouldn't assume that (although you'd be right as the language stands).
The intent was the prefixed notation only be used when no other
interpretation is possible (that is, it works like a use clause). Thus the
direct call to the entry would be prefered. Unfortunately, the rules for
that aren't actually in the RM.

Thus you might be right, in that you would have a risk of running into
another compiler bug. Of course, there is no requirement that the procedure
and the entry have the same name in this case, so the issue is easily
avoided.

> But, anyway, thanks a lot for the comments. I am waiting for comments
> from the guys who are in charge of the gnat compiler.

If you want that, you probably have to report a bug to them. This is an Ada
discussion group, not a bug reporting forum!

                                                   Randy.