Re: access types

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

On Sun, 01 Jul 2007 20:12:23 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 01 Jul 2007 10:57:17 -0400, Robert A Duff wrote:
>>
>>> Access-to-classwide should normally use "all".
>>> In fact, you won't go too far wrong if you always say "all"
>>> for all named access-to-variable types.
>>
>> I appreciate storage pools too much to agree with that. There are so many
>> interesting things we can do with pools, multiple inheritance for example!
>> (:-))
> 
> OK, I'll bite.  ;-)
> 
> How do you do multiple inheritance with pools?

Normally one would emulate MI with a mix-in:

type M (Base1 : access B1; Base2 : access B2) is new B3 with private;

The idea is to allocate M in a user pool. The pool would route Allocate and
Deallocate to the standard pool, but doing that Allocate would also reserve
some space for the instances of B1 and B2 in front of the object. M becomes
a pointer. Discriminants can eventually be removed if there is a way to
determine the addresses of B1 and B2 from a pointer (address) to B3.

This is of course a poor man's MI. But it works nicely for some things. For
example I used it for multiple doubly-linked lists of anything. An object
can stay in as many lists one could wish. For each list a record with Prev
and Next pointers is added when the object gets allocated in the pool.
Items of lists are accessed via plain access type, no further redirection
needed, no problem with unconstrained arrays as list items. Write "new
Thing", and the work is done.

> Anyway, "all" does not stop you from using pools.

In some cases it does. access all T is sort of doubly-dispatching. One of
its classes is T'Class, another is Root_Storage_Pool'Class.

The problem is that the second class is not available. We cannot define new
primitive operations which would dispatch on the pointer according to the
specific pool. Only Allocate and Deallocate would.

>> I could never understand why explicit conversion is not allowed for
>> pointers from the same pool.
> 
> Well, that might make sense, but we never thought of that.
> "Pool specific" is somewhat of a misnomer.  It really just
> means "Ada 83-style access type".

They fit nicely into Ada's OO model, as I described above. Maybe it was an
unexpected by-product. Which shows the strength of Ada's fundamentals.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de