* Specialization generic package parameters
@ 2008-05-23 17:29 Dmitry A. Kazakov
2008-05-23 20:17 ` christoph.grein
2008-05-24 12:48 ` Stephen Leake
0 siblings, 2 replies; 5+ messages in thread
From: Dmitry A. Kazakov @ 2008-05-23 17:29 UTC (permalink / raw)
Recently I ran into the following problem with generic packages. Consider
type T is tagged null record;
and a generic package that uses it:
generic
type Some_T is new T with private;
package P is
...
private
...
end P;
Let there be some type S derived from T:
type S is new T with null record;
Now the question is, how to derive another package Q from P, specialized
for S, while keeping access to the private part of P?
Neither of patterns I know works.
1. Nested package:
generic
type Some_S is new S with private;
package Q is
package P_S is new P (Some_S); -- This specializes P
private
-- No access to the private part of P!
end Q;
2. Formal package:
generic
type Some_S is new S with private;
package P_S is new P (Some_S); -- This specializes P
package Q is
...
private
-- No access to the private part of P!
end Q;
3. Child package
generic
package P.Q is
private
-- Got access to the private part, but
-- lost specialization, as the parameter
-- of P is no more constrained to S.
end P;
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Specialization generic package parameters
2008-05-23 17:29 Specialization generic package parameters Dmitry A. Kazakov
@ 2008-05-23 20:17 ` christoph.grein
2008-05-24 8:00 ` Dmitry A. Kazakov
2008-05-24 12:48 ` Stephen Leake
1 sibling, 1 reply; 5+ messages in thread
From: christoph.grein @ 2008-05-23 20:17 UTC (permalink / raw)
Why not a combination of 1+3:
generic
type Some_S is new S with private;
package P.Q is
private
-- has access to the private part of P
end P.Q;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Specialization generic package parameters
2008-05-23 20:17 ` christoph.grein
@ 2008-05-24 8:00 ` Dmitry A. Kazakov
0 siblings, 0 replies; 5+ messages in thread
From: Dmitry A. Kazakov @ 2008-05-24 8:00 UTC (permalink / raw)
On Fri, 23 May 2008 13:17:02 -0700 (PDT), christoph.grein@eurocopter.com
wrote:
> Why not a combination of 1+3:
>
> generic
> type Some_S is new S with private;
> package P.Q is
> private
> -- has access to the private part of P
> end P.Q;
But this would not constrain the parent P.
A typical example for the case is implementation of parallel types
hierarchies. For instance handles to the types T and S. (S <: T)
generic
type Some_T is new T with private;
package P
type T_Handle is private;
procedure Foo (O : T_Handle); -- Delegation to Foo of T
...
private
type T_Ptr is not null access all Some_T'Class;
type T_Handle is new Ada.Finalization.Controlled with record
Ptr : T_Ptr;
end record;
end P;
[ It is extremely tedious and error-prone to declare such delegation
wrappers to all primitive operations of T, but there is no any help for
this in Ada. ]
Now, let S, derived from T adds some new operations and there should be
specialized handles to S to accommodate to this:
generic
type Some_S is new S with private;
package P
type S_Handle is private; -- (or is new T_Handle with private)
-- New operations:
procedure Boo (O : S_Handle); -- Delegation to Boo of S
-- Old operations from T:
-- Oops, we should start all the mess again!
-- It seems that there is no way to re-use the wrappers declared in P,
-- by inheriting from T_Handle, without exposing private parts of
-- T_Handle (the variant 1). Alternatively, S_Handle should leave the
-- object pointer unconstrained, which would mean that delegators
-- would have to downcast them to S'Class (=distributed performance
-- hit) (the variant 3)
procedure Foo (O : T_Handle); -- Delegation to Foo of T
...
private
...
end P;
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Specialization generic package parameters
2008-05-23 17:29 Specialization generic package parameters Dmitry A. Kazakov
2008-05-23 20:17 ` christoph.grein
@ 2008-05-24 12:48 ` Stephen Leake
2008-05-24 14:07 ` Dmitry A. Kazakov
1 sibling, 1 reply; 5+ messages in thread
From: Stephen Leake @ 2008-05-24 12:48 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Recently I ran into the following problem with generic packages. Consider
>
> type T is tagged null record;
>
> and a generic package that uses it:
>
> generic
> type Some_T is new T with private;
> package P is
> ...
> private
> ...
> end P;
>
> Let there be some type S derived from T:
>
> type S is new T with null record;
>
> Now the question is, how to derive another package Q from P, specialized
> for S, while keeping access to the private part of P?
>
Factor out the types and operations currently in the private part of P
into a helper child package P.Ops.
Access those operations from Q:
4. New package
with P.Ops;
generic
type Some_S is new S with private;
package Q is
private
-- Got access to P.Ops, and have specialization
end P;
How would you do this in some other language?
--
-- Stephe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Specialization generic package parameters
2008-05-24 12:48 ` Stephen Leake
@ 2008-05-24 14:07 ` Dmitry A. Kazakov
0 siblings, 0 replies; 5+ messages in thread
From: Dmitry A. Kazakov @ 2008-05-24 14:07 UTC (permalink / raw)
On Sat, 24 May 2008 08:48:40 -0400, Stephen Leake wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Recently I ran into the following problem with generic packages. Consider
>>
>> type T is tagged null record;
>>
>> and a generic package that uses it:
>>
>> generic
>> type Some_T is new T with private;
>> package P is
>> ...
>> private
>> ...
>> end P;
>
>>
>> Let there be some type S derived from T:
>>
>> type S is new T with null record;
>>
>> Now the question is, how to derive another package Q from P, specialized
>> for S, while keeping access to the private part of P?
>>
> Factor out the types and operations currently in the private part of P
> into a helper child package P.Ops.
You mean to make adaptors to the things in the private part of P in order
to access them having only public view? This is same as to make everything
in P public. Same bad design but much less clutter...
> How would you do this in some other language?
I didn't think about it. C++ does not have contracted generics anyway.
----------------
[OT]
I always had an impression that generic children were poorly designed. They
should rather extend the parent, much like types extension does. When you
derive B from A, you become one new type. When you extend a generic P with
a generic P.Q, you get two packages, each to instantiate. Generic formal
parameters are analogous to discriminants:
type A (Par_1 : X) is tagged ...
type B (Par_2 : Y) is new A (Par_1 => <override discriminants>) with
record
<extend type>
end record;
generic
type Par_1 is ...
package P is ... end P;
generic -- This is not Ada!
type Par_2 is ...
package Q is new P (Par_1 => <override parameters>) with
<extend body>
end Q;
Between "Q is" and "new P" there probably should be a declarative region in
order to declare some things the overriding of parent's parameters could
refer to (without any visibility to P of course).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-05-24 14:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-23 17:29 Specialization generic package parameters Dmitry A. Kazakov
2008-05-23 20:17 ` christoph.grein
2008-05-24 8:00 ` Dmitry A. Kazakov
2008-05-24 12:48 ` Stephen Leake
2008-05-24 14:07 ` 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