From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6eac62e4f2badf3a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-07 07:47:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!newsfeed.r-kom.de!fu-berlin.de!uni-berlin.de!82-43-33-254.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Persistence of limited tagged types Date: Mon, 07 Apr 2003 15:47:27 +0100 Organization: ThoughtWing Computer Software Message-ID: References: NNTP-Posting-Host: 82-43-33-254.cable.ubr01.croy.blueyonder.co.uk (82.43.33.254) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed X-Trace: fu-berlin.de 1049726848 8832645 82.43.33.254 (16 [25716]) In-Reply-To: User-Agent: Opera7.03/Win32 M2 build 2670 Xref: archiver1.google.com comp.lang.ada:35965 Date: 2003-04-07T15:47:27+01:00 List-Id: On Mon, 7 Apr 2003 14:47:36 +0200, Jano 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]