Re: Persistence of limited tagged types

[Nick Roberts <nickroberts@blueyonder.co.uk>]

On Mon, 7 Apr 2003 14:47:36 +0200, Jano <nono@celes.unizar.es> wrote:

> I've read several past threads about this, but to reassure me I want to 
> bring it back again, or at least to know the typical workaround.
>
> I have a heterogeneous collection by means of class wide access types, 
> where the accessed types itself are descendants of a
>
> type Object is abstract tagged limited private;
>
> These objects are kind of state-dependent, and I have an abstract method 
> which serializes an Object to disk. So far, so good.
>
> The problem comes when I want to reconstruct the collection from disk. I 
> can't think of a mean to obtain a valid allocated pointer initialized 
> with some dispatching call.
>
> A neat solution could be a function that returned an allocated pointer 
> given a tag, but AFAIK there is not such a function.
>
> I think that my only option is to make the type non-limited and couple it 
> somehow with the limited components. It's not a so hard change at this 
> stage, but I'd be glad to know other people takes on this problem.

Speaking (all right writing) 'off the cuff' as it were, my attitude is that 
limited types are (supposed to be) inherently not the kind of types which 
are persistent (serialisable).

I would expect your type (hierarchy) to be non-limited if it is 
serialisable; possibly this is a slightly purist point of view.

For serialisation, I would normally expect T'Read and T'Write to be 
redefined for every type T in the hierarchy whenever the defaults did not 
suffice (or some guarantees of portability or longevity, of data or code or 
both, are required). A suitable T'Read and T'Write will also have to be 
available for every type T of all the discriminants used in all the types 
in the hierarchy.

Then you simply use T'Output to write out a value of a type in the 
hierarchy, and T'Input (a function) to read in a value (of any type) in the 
hierarchy.

If you really intend to be serialising limited types, I suspect that (both 
theoretically and practically) you need to have intermediate non-limited 
types to help you. Serialisation of a limited type will then involve: 
conversion to and from a suitable non-limited type; serialisation of the 
non-limited type.

To illustrate this idea, suppose you have a limited type Bank_Account. To 
save an object of type Bank_Account, you might first convert the object, 
perhaps as a result of an operation such as Suspend_Account, to a value of 
the non-limited type Suspended_Account (which might contain the balance of 
the account, a list of outstanding transactions, and so on), and then save 
the Suspended_Account. To load a Bank_Account, you would first load a 
Suspended_Account, and then construct an object of type Bank_Account from 
it, perhaps with an operation such as Reactivate_Account.

My point is that you cannot (generally) just naively save and load a 
limited type (such as Bank_Account), because more logic than that is almost 
certain to be required (for example, the actions of suspending and 
reactivating the account).

Hope this helps.

-- 
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]