Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2014-05-01, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
> On 01/05/14 08:54, Natasha Kerensikova wrote:
>> Is it possible, or am I hitting a limit of Ada generics?
>
> For what it's worth, the generic is requesting a formal
> type T, but not T's "construction facilities".  To assume,
> then, that the generic should be able to properly construe
> objects of type T seems misguided. (The in-place construction
> cannot incidentally "rectify" the structure of the solution,
> I think. The split remains.)
>
> Approaching the subject of opaque automatic memory management
> is ambitious, in particular if using the same approach for
> different kinds of type with the help of a generic: an "adequately
> declared" formal of Allocate is by its nature a client-side thing
> here, it cannot be provided by the generic, I think.

Ideally, the client builds an object, which is held by the generic
package until it's no longer used. Initialization is necessarily split
between both worlds, since the client must provide the constraints and
the values, while the actual storage belongs to the realm of the generic
package.

As I wrote in the other thread, I have a working solution by shifting
the allocation to the client, and having the reference-construction
subprogram use an access value provided by the client.
I'm only trying to avoid this solution because I don't understand the
abstraction-breach risks of making the access type public.

And all this is still in Ada 2005. Ada 2012 adding subpool specification
to allocators raises the question of whether subpool specification
should be part of the client or of the generic package, and I have no
clue of which is best, or which compromises are involved in both
possibilities.

> Since your specific problems seem to be about the two kinds of
> type Storage_Element_Array and Root_Stream_Type'Class only,
> I wonder if you could just address these, more specifically?

Actually I use the generic package with a wide variety of types, and I
already have a quite a bit of code depending on its current form.

I've referred to these two examples because they are the simplest while
covering all my use cases, so that any solution that work on both
examples is very likely to work for all my needs.


Thanks for your help,
Natasha