Specialization generic package parameters

Specialization generic package parameters

[Dmitry A. Kazakov]

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

Re: Specialization generic package parameters

[christoph.grein]

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;

Re: Specialization generic package parameters

[Dmitry A. Kazakov]

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

Re: Specialization generic package parameters

[Stephen Leake]

"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

Re: Specialization generic package parameters

[Dmitry A. Kazakov]

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