* Delegating operations to parent (generic formal type)
@ 2000-07-13 0:00 Simon Wright
2000-07-13 0:00 ` tmoran
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Simon Wright @ 2000-07-13 0:00 UTC (permalink / raw)
The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
APEX 3.2.0b (Solaris) or the OA demo edition.
The problem arises in the body of Containers.Maps.Synchronized.
APEX says it can't resolve the call Initialize (Map_Base (M)) in
Containers.Maps.Synchronized.Initialize.
OA says the call to Bind (Map_Base (M)) is a non-dispatching call on
an abstract subprogram. I think it may be confused, it mutters also
about "internal error".
This is a pretty common idiom in Smalltalk (super bind, super
initialize) -- is there an Ada equivalent that would help here? I can
believe that OA is wrong, it's very old now, but I can't see why APEX
doesn't see the Initialize(Map_Base) operation.
=============================================================================
with Ada.Finalization;
package Containers is
type Container is abstract tagged private;
private
type Container is abstract new Ada.Finalization.Controlled with null record;
end Containers;
package Containers.Maps is
type Map is abstract new Container with private;
procedure Bind (M : in out Map) is abstract;
private
type Map is abstract new Container with null record;
end Containers.Maps;
package Containers.Maps.Unbounded is
type Unbounded_Map is new Map with private;
procedure Bind (M : in out Unbounded_Map);
private
type Unbounded_Map is new Map with null record;
procedure Initialize (M : in out Unbounded_Map);
end Containers.Maps.Unbounded;
package body Containers.Maps.Unbounded is
procedure Bind (M : in out Unbounded_Map) is
begin
null;
end Bind;
procedure Initialize (M : in out Unbounded_Map) is
begin
null;
end Initialize;
end Containers.Maps.Unbounded;
generic
type Map_Base is new Containers.Maps.Map with private;
package Containers.Maps.Synchronized is
type Synchronized_Map is new Map_Base with private;
procedure Bind (M : in out Synchronized_Map);
private
type Synchronized_Map is new Map_Base with null record;
procedure Initialize (M : in out Synchronized_Map);
end Containers.Maps.Synchronized;
package body Containers.Maps.Synchronized is
procedure Bind (M : in out Synchronized_Map) is
begin
Bind (Map_Base (M)); -- this is OK in APEX
end Bind;
procedure Initialize (M : in out Synchronized_Map) is
begin
Initialize (Map_Base (M)); -- this is complained about
end Initialize;
end Containers.Maps.Synchronized;
with Containers.Maps.Synchronized;
with Containers.Maps.Unbounded;
package User is
package Synchronized_Unbounded_Map
is new Containers.Maps.Synchronized
(Map_Base => Containers.Maps.Unbounded.Unbounded_Map);
end User;
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-07-13 0:00 Delegating operations to parent (generic formal type) Simon Wright
@ 2000-07-13 0:00 ` tmoran
2000-07-14 0:00 ` Simon Wright
2000-07-14 0:00 ` Simon Wright
2000-08-28 0:00 ` Simon Wright
2 siblings, 1 reply; 9+ messages in thread
From: tmoran @ 2000-07-13 0:00 UTC (permalink / raw)
If you delete procedure Initialize from package Containers.Maps.Unbounded,
then what procedure is supposed to be called by
Initialize (Map_Base (M)); -- this is complained about
in package Containers.Maps.Synchronized?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-07-13 0:00 ` tmoran
@ 2000-07-14 0:00 ` Simon Wright
0 siblings, 0 replies; 9+ messages in thread
From: Simon Wright @ 2000-07-14 0:00 UTC (permalink / raw)
tmoran@bix.com writes:
> If you delete procedure Initialize from package Containers.Maps.Unbounded,
> then what procedure is supposed to be called by
> Initialize (Map_Base (M)); -- this is complained about
> in package Containers.Maps.Synchronized?
What I would _hope_ is that the default (null) one in Ada.Finalization
would get called. Or, if Containers had one, then that one.
I did try Initialize (Map_Base'Class (M)) but that ends up being a
recursive call to Containers.Maps.Synchronized.Initialize .
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-07-13 0:00 Delegating operations to parent (generic formal type) Simon Wright
2000-07-13 0:00 ` tmoran
@ 2000-07-14 0:00 ` Simon Wright
2000-07-15 0:00 ` Simon Wright
2000-08-28 0:00 ` Simon Wright
2 siblings, 1 reply; 9+ messages in thread
From: Simon Wright @ 2000-07-14 0:00 UTC (permalink / raw)
Christoph Grein <christoph.grein@eurocopter.de> can't post directly,
but says:
It's really funny, I've just published an article about this
behaviour in the Ada Germany's periodical. You can find the English
version on my homepage and also in AdaPower in the Language section.
http://home.T-Online.de/home/Christ-Usch.Grein/AdaMagica/Secretive.html
You'll find the problem solution there.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-07-14 0:00 ` Simon Wright
@ 2000-07-15 0:00 ` Simon Wright
0 siblings, 0 replies; 9+ messages in thread
From: Simon Wright @ 2000-07-15 0:00 UTC (permalink / raw)
Simon Wright <simon@pogner.demon.co.uk> writes:
> Christoph Grein <christoph.grein@eurocopter.de> can't post directly,
> but says:
>
> It's really funny, I've just published an article about this
> behaviour in the Ada Germany's periodical. You can find the English
> version on my homepage and also in AdaPower in the Language section.
>
> http://home.T-Online.de/home/Christ-Usch.Grein/AdaMagica/Secretive.html
>
> You'll find the problem solution there.
Christoph,
Your article is about the fact that primitive operations can only
override visible operations of a parent type.
Although I take your point, in my case the operations were in a child
package -- exactly like yours! -- so the inheritance from
Ada.Finalization.Controlled should have been visible.
Interestingly, when I made the inheritance public, Apex crashed in the
"middle pass" (AFAICR).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-07-13 0:00 Delegating operations to parent (generic formal type) Simon Wright
2000-07-13 0:00 ` tmoran
2000-07-14 0:00 ` Simon Wright
@ 2000-08-28 0:00 ` Simon Wright
2000-08-29 0:00 ` Tucker Taft
2 siblings, 1 reply; 9+ messages in thread
From: Simon Wright @ 2000-08-28 0:00 UTC (permalink / raw)
(This is a repost, in the hope someone can help!!)
The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
APEX 3.2.0b (Solaris) or the OA special edition (7.2).
The problem arises in the body of Containers.Maps.Synchronized.
APEX says it can't resolve the call Initialize (Map_Base (M)) in
Containers.Maps.Synchronized.Initialize.
OA ditto, followed by a fatal assertion error (or was it a bad memory
access?) in the instantiation.
This is a pretty common idiom in Smalltalk (super bind, super
initialize) -- is there an Ada equivalent that would help here? I
can't see why the compilers don't see the Initialize(Map_Base)
operation, we're in a child package and should be able to see the
private operations of Map_Base -- which include those of Controlled.
=============================================================================
with Ada.Finalization;
package Containers is
type Container is abstract tagged private;
private
type Container is abstract new Ada.Finalization.Controlled with null record;
end Containers;
package Containers.Maps is
type Map is abstract new Container with private;
procedure Bind (M : in out Map) is abstract;
private
type Map is abstract new Container with null record;
end Containers.Maps;
package Containers.Maps.Unbounded is
type Unbounded_Map is new Map with private;
procedure Bind (M : in out Unbounded_Map);
private
type Unbounded_Map is new Map with null record;
procedure Initialize (M : in out Unbounded_Map);
end Containers.Maps.Unbounded;
package body Containers.Maps.Unbounded is
procedure Bind (M : in out Unbounded_Map) is
begin
null;
end Bind;
procedure Initialize (M : in out Unbounded_Map) is
begin
null;
end Initialize;
end Containers.Maps.Unbounded;
generic
type Map_Base is new Containers.Maps.Map with private;
package Containers.Maps.Synchronized is
type Synchronized_Map is new Map_Base with private;
procedure Bind (M : in out Synchronized_Map);
private
type Synchronized_Map is new Map_Base with null record;
procedure Initialize (M : in out Synchronized_Map);
end Containers.Maps.Synchronized;
package body Containers.Maps.Synchronized is
procedure Bind (M : in out Synchronized_Map) is
begin
Bind (Map_Base (M)); -- this is OK in APEX
end Bind;
procedure Initialize (M : in out Synchronized_Map) is
begin
Initialize (Map_Base (M)); -- this is complained about
end Initialize;
end Containers.Maps.Synchronized;
with Containers.Maps.Synchronized;
with Containers.Maps.Unbounded;
package User is
package Synchronized_Unbounded_Map
is new Containers.Maps.Synchronized
(Map_Base => Containers.Maps.Unbounded.Unbounded_Map);
end User;
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-08-28 0:00 ` Simon Wright
@ 2000-08-29 0:00 ` Tucker Taft
2000-09-06 5:25 ` Simon Wright
0 siblings, 1 reply; 9+ messages in thread
From: Tucker Taft @ 2000-08-29 0:00 UTC (permalink / raw)
Simon Wright wrote:
>
> (This is a repost, in the hope someone can help!!)
>
> The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
> APEX 3.2.0b (Solaris) or the OA special edition (7.2).
>
> The problem arises in the body of Containers.Maps.Synchronized.
>
> APEX says it can't resolve the call Initialize (Map_Base (M)) in
> Containers.Maps.Synchronized.Initialize.
>
> OA ditto, followed by a fatal assertion error (or was it a bad memory
> access?) in the instantiation.
>
> This is a pretty common idiom in Smalltalk (super bind, super
> initialize) -- is there an Ada equivalent that would help here? I
> can't see why the compilers don't see the Initialize(Map_Base)
> operation, we're in a child package and should be able to see the
> private operations of Map_Base -- which include those of Controlled.
The use of Initialize is legal. This looks like an old-fashioned
bug in APEX and ObjectAda 7.2. The current AdaMagic front end has no
problem "seeing" the Initialize operation.
-Tuck
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-08-29 0:00 ` Tucker Taft
@ 2000-09-06 5:25 ` Simon Wright
2000-09-07 21:56 ` Tucker Taft
0 siblings, 1 reply; 9+ messages in thread
From: Simon Wright @ 2000-09-06 5:25 UTC (permalink / raw)
Tucker Taft <stt@averstar.com> writes:
> The use of Initialize is legal. This looks like an old-fashioned
> bug in APEX and ObjectAda 7.2. The current AdaMagic front end has no
> problem "seeing" the Initialize operation.
Tucker,
Thanks very much. I'll pass on PRs ..
The following is a repost of my article "Visibility for operations of
formal private extensions" <x7v4s5af41m.fsf@pogner.demon.co.uk> which
seems to have similar difficulty. I'd be most grateful for any
comments ..
The code below gives compilation errors when compiling the view
conversion in P.Q.R.Proc's body, both in GNAT (3.13a1) and Apex
3.2.0b. They say that there's no visible interpretation: GNAT says
/home/simon/tmp/demo.ada:33:09: no candidate interpretations match the actuals:
/home/simon/tmp/demo.ada:33:15: expected type "New_T" defined at /home/simon/tmp/demo.ada:26
/home/simon/tmp/demo.ada:33:15: found private type "Base" defined at /home/simon/tmp/demo.ada:22
/home/simon/tmp/demo.ada:33:15: ==> in call to "Proc" at /home/simon/tmp/demo.ada:27
/home/simon/tmp/demo.ada:33:15: ==> in call to "Proc" at /home/simon/tmp/demo.ada:18(inherited)
/home/simon/tmp/demo.ada:33:15: ==> in call to "Proc" at /home/simon/tmp/demo.ada:5
If I make P.Proc publicly visible, the compilation goes fine.
I believe we are somewhere near 12.5.1(21) here. My belief that it
should have compiled is based on the following:
* we know that P.Q.R.Base is a P.Q.Q_T
* a P.Q.Q_T (privately) inherits P.Proc
* P.Q.R's body has visiblity of the private part of P and therefore
should be able to see that P.Q.Q_T inherits P.Proc
Note that P.Q.S's body _can_ see P.Proc.
I tried adding a private component to P.Q.Q_T, P.Q.R.Proc can see it
quite happily .. OK, the LRM reference above is about operations not
data, still!
==================================================================
package P is
type T is tagged private;
private
type T is tagged null record;
procedure Proc (The_T : in out T);
end P;
package body P is
procedure Proc (The_T : in out T) is
begin
null;
end Proc;
end P;
package P.Q is
type Q_T is new P.T with private;
private
type Q_T is new T with null record;
end P.Q;
generic
type Base is new Q_T with private;
package P.Q.R is
type New_T is new Base with private;
private
type New_T is new Base with null record;
procedure Proc (The_T : in out New_T);
end P.Q.R;
package body P.Q.R is
procedure Proc (The_T : in out New_T) is
begin
Proc (Base (The_T));
end Proc;
end P.Q.R;
package P.Q.S is
type S_T is new Q_T with private;
private
type S_T is new Q_T with null record;
procedure Proc (The_T : in out S_T);
end P.Q.S;
package body P.Q.S is
procedure Proc (The_T : in out S_T) is
begin
Proc (Q_T (The_T));
end Proc;
end P.Q.S;
with P.Q.R;
with P.Q.S;
package U is
package U_P is new P.Q.R (Base => P.Q.S.S_T);
end U;
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Delegating operations to parent (generic formal type)
2000-09-06 5:25 ` Simon Wright
@ 2000-09-07 21:56 ` Tucker Taft
0 siblings, 0 replies; 9+ messages in thread
From: Tucker Taft @ 2000-09-07 21:56 UTC (permalink / raw)
Simon Wright wrote:
>
> Tucker Taft <stt@averstar.com> writes:
>
> > The use of Initialize is legal. This looks like an old-fashioned
> > bug in APEX and ObjectAda 7.2. The current AdaMagic front end has no
> > problem "seeing" the Initialize operation.
>
> Tucker,
>
> Thanks very much. I'll pass on PRs ..
>
> The following is a repost of my article "Visibility for operations of
> formal private extensions" <x7v4s5af41m.fsf@pogner.demon.co.uk> which
> seems to have similar difficulty. I'd be most grateful for any
> comments ..
This also looks like the same bug. The body of a generic should
be able to see the private operations in its parent unit.
> ...
-Tuck
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-09-07 21:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-13 0:00 Delegating operations to parent (generic formal type) Simon Wright
2000-07-13 0:00 ` tmoran
2000-07-14 0:00 ` Simon Wright
2000-07-14 0:00 ` Simon Wright
2000-07-15 0:00 ` Simon Wright
2000-08-28 0:00 ` Simon Wright
2000-08-29 0:00 ` Tucker Taft
2000-09-06 5:25 ` Simon Wright
2000-09-07 21:56 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox