changing rules for anonymous access types to named ones

changing rules for anonymous access types to named ones

[Jean-Claude Rostaing]

Hi.
There's definitely a change in rules from 95 to 2012 I spotted, which makes things more ugly:
that: Set(new Plus_Operator);
was written for ada95. Now, it gives the error:
expected type "TOKEN_ACCESS" defined at expressions.ads:22
found type access to "Plus_Operator" defined at line 48
TOKEN_ACCESS is merely a named access type to TOKEN_TYPE'class, which PLUS_OPERATOR is a child of.

I made a compilable exemple of my case:

with ada.Text_IO;
use ada.Text_IO;
procedure ESSAI is
   type A is abstract tagged limited null record;
   type A_Child is new A with null record;
   type pointers_A is access A'CLASS;
   type B is interface;
   type B_child is new B with null record;
   type pointers_B is access b'CLASS;
   function F1 (obj: pointers_A) return INTEGER is (1);
   function F2 (obj: pointers_b) return INTEGER IS (1);
begin
   PUT_LINE("avec abstract tagged null record : " & INTEGER'IMAGE(F1(new A_child));
   Put_Line("AVEC interface : " & INTEGER'IMAGE(F2(new B_child));
end;

Only the second statement fails. I could find nothing in the access type section related to interface nor the reciprocal so I'm sure it's not normal.

Re: changing rules for anonymous access types to named ones

[Jere]

On Monday, April 2, 2018 at 12:39:38 PM UTC-4, Jean-Claude Rostaing wrote:
> Hi.
> There's definitely a change in rules from 95 to 2012 I spotted, which makes things more ugly:
> that: Set(new Plus_Operator);
> was written for ada95. Now, it gives the error:
> expected type "TOKEN_ACCESS" defined at expressions.ads:22
> found type access to "Plus_Operator" defined at line 48
> TOKEN_ACCESS is merely a named access type to TOKEN_TYPE'class, which PLUS_OPERATOR is a child of.
> 
> I made a compilable exemple of my case:
> 
> with ada.Text_IO;
> use ada.Text_IO;
> procedure ESSAI is
>    type A is abstract tagged limited null record;
>    type A_Child is new A with null record;
>    type pointers_A is access A'CLASS;
>    type B is interface;
>    type B_child is new B with null record;
>    type pointers_B is access b'CLASS;
>    function F1 (obj: pointers_A) return INTEGER is (1);
>    function F2 (obj: pointers_b) return INTEGER IS (1);
> begin
>    PUT_LINE("avec abstract tagged null record : " & INTEGER'IMAGE(F1(new A_child));
>    Put_Line("AVEC interface : " & INTEGER'IMAGE(F2(new B_child));
> end;
> 
> Only the second statement fails. I could find nothing in the access type section related to interface nor the reciprocal so I'm sure it's not normal.

I don't think interfaces were part of 95 and they may have different rules 
versus an abstract record.  However, you can change your access type to a
general access type to solve the compilation error:

 type pointers_B is access all b'CLASS; 

Re: changing rules for anonymous access types to named ones

[Jean-Claude Rostaing]

> general access type to solve the compilation error:
Yeah, but it's ugly and I won't write "access all" if if I'm not really gonna use a pointer on the stack...
I think it's a compiler issue, as like I said, I found no rules about access types, in the interface issue. Also, the interface are said to be pretty much equivalent to "type blablabla is abstract tagged null record"....

Re: changing rules for anonymous access types to named ones

[Dmitry A. Kazakov]

On 02/04/2018 23:09, Jean-Claude Rostaing wrote:
>> general access type to solve the compilation error:
> Yeah, but it's ugly and I won't write "access all" if if I'm not really gonna use a pointer on the stack...
> I think it's a compiler issue, as like I said, I found no rules about access types, in the interface issue. Also, the interface are said to be pretty much equivalent to "type blablabla is abstract tagged null record"....

    Interface = abstract type - representation - bodies of operations

There should have been none in this form, just abstract types + multiple 
inheritance.

P.S. Interfaces should be anonymous, e.g. T'Interface, the interface of 
the type T. So that you could derive from T dropping its representation 
and implementations of all operations. For example:

    type My_Custom_Integer is new Integer'Interface with record
       -- Whatever I see appropriate to represent integer
    end record;
    -- overriding all operations, since they are inherited abstract

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: changing rules for anonymous access types to named ones

[Jean-Claude Rostaing]

>     type My_Custom_Integer is new Integer'Interface with record
>        -- Whatever I see appropriate to represent integer
>     end record;
>     -- overriding all operations, since they are inherited abstract
If you want a view conversion INTEGER(any_type_inheriting_INTEGER'Interface) to works, you should also inheriting also all attributes of Integer, or of any numeric type which providing the interface ?
But I suppose your model could work if you were to limit 'Interface to tagged types, records tasks and protected types.

Re: changing rules for anonymous access types to named ones

[Dmitry A. Kazakov]

On 03/04/2018 13:29, Jean-Claude Rostaing wrote:
>>      type My_Custom_Integer is new Integer'Interface with record
>>         -- Whatever I see appropriate to represent integer
>>      end record;
>>      -- overriding all operations, since they are inherited abstract
> If you want a view conversion INTEGER(any_type_inheriting_INTEGER'Interface) to works,

That is an upcast conversion since Integer'Interface'Class is not in 
Integer'Class.

> you should also inheriting also all attributes of Integer, or of any numeric type which providing the interface ?

Yes. All object attributes should have been primitive operations. Type 
attributes are free operations.

> But I suppose your model could work if you were to limit 'Interface to tagged types, records tasks and protected types.

For by-value types conversion T -> T'Class is a full conversion.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de