Re: Type conversions on pool-specific access types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Nick Roberts wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:g5ksovoq9nkg0tb53rgrn40vjjl7l5cqkb@4ax.com...
> 
>> > ...
>> >   declare
>> >      Ptr : Base_Ptr := new Derived;
>> >   begin
>> >      Foo(Ptr);
>>
>> Yes, in this case. But consider specialized containers of
>> Derived descendants:
>>
>> procedure Derived_Specific (X : Derived);
>> type Array_Of_Derived is array (...) of Derived_Ptr;
>>
>> Now you can call Derived_Specific on any element of
>> Array_Of_Derived without an explicit type conversion.
>> It is also type safe. If I have only Base_Ptr, I lose that
>> advantage and forced to always work in the terms of
>> the base type and what is worse, to make casts.
> 
> In this situation, I suggest you declare:
> 
>    type Derived_Ptr is access Derived'Class;
>    type Array_Of_Derived is array (...) of Derived_Ptr;
> 
> exactly as you suggest, so you can call:
> 
>    Derived_Specific( Array_Of_Derived(...).all );
> 
> If you now wish to call Foo for an object designated by a component of the
> Array_Of_Derived array, you do indeed need to do a conversion. I think
> this can be adequately achieved in Ada 95 by the use of an intermediate
> general access type:
> 
>    type General_Base_Ptr is access all Base'Class;
>    procedure Foo (Object: in General_Base_Ptr);

Which in effect just means that we abadon use of pool-specific access types.

Say, we introduce the language design principle:

"a program dealing with objects allocated in ONE pool should to remain valid
after removing the word "all" in all access type declarations."

Don't you think it would be a reasonable principle? [ Note that all nasty
cases of 'Unchecked_Access are excluded by the one-pool-requirement. ] 

>> [Finalize should not deallocate Object]
>> Theoretically true, but practically, consider a situation
>> when objects have to be always allocated in a specific
>> pool. For example, on a user-defined stack. Further each
>> object has to remove itself from some list. It is made
>> upon finalization. The problem is that in this case you
>> cannot use the advantages of thin pool-specific pointers.
> 
> I repeat that a controlled object should not attempt to deallocate itself
> during its own finalisation.

It is not what required. What is required is that the object could delete
itself from a global list [of pointers] upon finalization. For this a
pointer to the object is needed. So you have to get a pointer to the object
[of a limited type of course]. This is impossible for pool-specific access
types. And I see no solution for that. Here I mean not a work-around, but
how to fix it in Ada design.

First of all the anonymous access types are general-access types. Otherwise,
one could try to define Finalize [Initialize] for limited controlled types
as:

   procedure Finalize (Object_Ptr : access Object_Type);

as opposed to

   procedure Finalize (Object_Ptr : access all Object_Type);

But then the actual storage pool of Object_Ptr would not be statically
known. So it would not work anyway. And it is too late of course. So the
situation with pool-specific access types is pretty grim at the moment.

Not to mention other problems with storage pools:

1. How to make a user-defined storage pool usable both concurrently and
inside a protected operation?

2. How to have task-specific storage pools, when task are created
dynamically?

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de