Re: Getting the index for an element in mutually referencing containers

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

On 2017-03-11 09:40, Simon Wright wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Mart van de Wege" <mvdwege@gmail.com> wrote in message
>> news:86wpbxneuz.fsf@gaheris.avalon.lan...
>>> Simon Wright <simon@pushface.org> writes:
>> ...
>>>> But, I really think you're going to need to use access types here. A
>>>> Person is a unique object, and should only exist once in your data
>>>> structures. A Child should hold references to its Parent(s) and vice
>>>> versa; if a Child holds *copies* of its Parents, what happens when
>>>> you change the Parent's data in one place? how are you going to find
>>>> all the copies and change all of them?
>>>>
>>> That was what I was afraid of. I like the way Ada usually takes care
>>> of this for you, but I've been trying to work it out during downtime
>>> today at work, and I'm afraid it's indeed time to grab the access
>>> types out of the toolbox.
>>
>> The trick in such cases is to have a global "person" vector, which
>> contains all of the actual Person objects. Then use the cursors into
>> that array in your other data structures. That's gives the needed
>> level of indirection without involving any actual access types
>> (meaning that you let Ada do the storage management, and depending on
>> your container implementation, also reduce/eliminate the danger of
>> dangling access types).
>
> In the general case, you'd need to cope with deleting (the equivalent
> of) Person objects.
>
> And wouldn't even appending a new Person risk invalidating any existing
> cursors? AARM A18(5.k) says "Cursors *generally* remain valid as long as
> the container exists and the element referenced is not deleted",
> emphasis added. AdaCore's Vector implementation would be OK with
> inserting elements _after_ the Cursor concerned, since the Cursor is
> based on an index into an array. See discussion at AARM A18.2(240) ff.
>
> I quite like the idea of using an indefinite container to hold the
> Person objects, but I think I'd use a Map with the key an integer
> (Natural?), with the next key held in a private global, incremented as
> each new Person is created. The reference to a Person would be the
> associated key.

This looks like a clear case for reference counted objects. A handle to 
Person to be put into containers (for search) and into other objects for 
referencing. No problem with limited types. Weak handles are for 
backward referencing and so on.

I often start with a container only to be forced to switch to reference 
counting later, especially when the objects are mutable. There is no 
good containers for mutable types except for built-in arrays.

> One disadvantage to this design is that Containers hold non-limited
> types. Your users run the risk of writing code that gets hold of a copy
> of the object and modifies that, rather than modifying the actual
> object.

A transaction sort of schema can be implemented on top of reference 
counting. E.g. if the count > 1 you clone the object you want to modify.

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