Re: Design of cross referring types/classes and proper usage of containers

[Serge Robyns <serge.robyns@gmail.com>]

On Wednesday, 5 August 2015 09:37:20 UTC+2, Dmitry A. Kazakov  wrote:
> On Tue, 4 Aug 2015 12:00:28 -0700 (PDT), Serge Robyns wrote:
> 
> > Given static (immutable data) one one hand and dynamic data (changed
> > during the execution) on the other hand; stored in various containers. 
> > What is actually the best approach? Shall I Storing the full element of
> > objects or references created through new T_xyz?
> 
> That depends on the semantics of mutators. If the semantics is referential,
> e.g. you change the object in one place and all logical references get
> aware of the change, the only way (that does not involve global variables
> and distributed overhead) is having physical references.

I've indeed two instances of such objects so far.  This allows me to use a "setter" like Obj.Change (Value), once I've pulled them from on of the containers (through indirection).  (BTW I do love the Ada 2012 changes to containers.)  In my first attempt, I stored them in their referring object through an access type (for speed), now I'm storing their key in their referring object and use it to find them in their respective containers.  I've been thinking on returning a Cursor but then I'm exposing the implementation and require to put the container definition into the specification package of the package building the these containers.

My end goal is to use a Proxy pattern, allowing the data to be retrieved from a XML file (ideal for test automation) or from a database (in production mode).  In the case of the XML file, the whole data gets loaded at once into containers, whereas for a database approach, specific SQL statements will retrieve the data by these proxies.  The users of the objects shouldn't notice the implementation.

> 
> Things like MVC require referential semantics.
> 
> > Shall I Storing the full element of
> > objects or references created through new T_xyz?
> 
> You could have a constructing function that hides ugly allocator. E.g. when
> using strong references you might have:
> 
>     function Create (...) return Handle;
> 
> which internally allocates some private limited object the tagged Handle
> points to. Handle can be copied around and stored into a container. [*]
> 

Limited objects is one of these things I'm struggling getting my head around.  I will need to (re)read about it to fully understand their purpose as for now I perceive them as a pain.