🚀 go-pugleaf

In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to dsouza@optima.cad.mcc.com (Desmond Dsouza):
>...
>>1. Persistent objects: When reading in one of these from disk, you
>>   need to know what constructor to call. Hence you need to encode in
>>   the persistent image the ClassId of the object.
>
>Presumably, a well-designed class hierarchy will use a virtual
>function to store objects; and a virtual function by definition will
>already know the exact type of the object it is storing.
>

  This view of how to implement persistence seems narrow.  Researchers
and vendors have taken a number of implementation approaches, including
the one you mention.  The details of the various implementations vary
widely, but few depend on virtual functions to supply type information.
In all cases some indication of the actual type of the stored object
must be available when the object is recovered.  Of course, this
implies type information must be available when an object is to be
stored.  I daresay many of us working in the area of persistence would
welcome a standard way of encoding and accessing type information.

  Actually the problem generalizes quite readily to exporting and
importing an object from and to an address space, regardless of the
purpose.  An obvious purpose, other than storage, is for interprocess
communications.

>...
>-- 
>Chip Salzenberg at Teltronics/TCT      <chip@tct.uucp>, <uunet!pdn!tct!chip>
>"It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber
>   (with reference to the upage bug in Interactive UNIX and Everex ESIX)
Bob Peterson                Compuserve: 70235,326          Expressway Site,
Texas Instruments           Internet: peterson@csc.ti.com   North Building,
P.O. Box 655474, MS238      Landline: (214) 995-6080         2nd Floor,
Dallas, Texas, USA 75265                                      CSC Aisle C3