* changing rules for anonymous access types to named ones
@ 2018-04-02 16:39 Jean-Claude Rostaing
2018-04-02 18:04 ` Jere
0 siblings, 1 reply; 6+ messages in thread
From: Jean-Claude Rostaing @ 2018-04-02 16:39 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: changing rules for anonymous access types to named ones
2018-04-02 16:39 changing rules for anonymous access types to named ones Jean-Claude Rostaing
@ 2018-04-02 18:04 ` Jere
2018-04-02 21:09 ` Jean-Claude Rostaing
0 siblings, 1 reply; 6+ messages in thread
From: Jere @ 2018-04-02 18:04 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: changing rules for anonymous access types to named ones
2018-04-02 18:04 ` Jere
@ 2018-04-02 21:09 ` Jean-Claude Rostaing
2018-04-03 8:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 6+ messages in thread
From: Jean-Claude Rostaing @ 2018-04-02 21:09 UTC (permalink / raw)
> 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"....
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: changing rules for anonymous access types to named ones
2018-04-02 21:09 ` Jean-Claude Rostaing
@ 2018-04-03 8:41 ` Dmitry A. Kazakov
2018-04-03 11:29 ` Jean-Claude Rostaing
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry A. Kazakov @ 2018-04-03 8:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: changing rules for anonymous access types to named ones
2018-04-03 8:41 ` Dmitry A. Kazakov
@ 2018-04-03 11:29 ` Jean-Claude Rostaing
2018-04-03 12:44 ` Dmitry A. Kazakov
0 siblings, 1 reply; 6+ messages in thread
From: Jean-Claude Rostaing @ 2018-04-03 11:29 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: changing rules for anonymous access types to named ones
2018-04-03 11:29 ` Jean-Claude Rostaing
@ 2018-04-03 12:44 ` Dmitry A. Kazakov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2018-04-03 12:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-04-03 12:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-02 16:39 changing rules for anonymous access types to named ones Jean-Claude Rostaing
2018-04-02 18:04 ` Jere
2018-04-02 21:09 ` Jean-Claude Rostaing
2018-04-03 8:41 ` Dmitry A. Kazakov
2018-04-03 11:29 ` Jean-Claude Rostaing
2018-04-03 12:44 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox