🚀 go-pugleaf

In article <27CD159D.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to peterson@choctaw.csc.ti.com (Bob Peterson):
>>In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>>Presumably, a well-designed class hierarchy will use a virtual
>>>function to store objects ...
>>
>>Researchers and vendors have taken a number of implementation approaches
>>...  The details of the various implementations vary widely, but few depend
>>on virtual functions to supply type information.

>Is there any reason to avoid virtual functions for object storage?

>I had not envisioned a virtual function to return type information,
>but rather a virtual function to actually _do_the_work_, so no one
>outside of that function need know the actual type of the object
>stored.  

  Several solutions exist to the problem of persistence.  Basing a
solution on virtual functions is only one approach.  I failed to
clearly make my point: virtual functions are not the only foundation on
which to build persistence.  I know you don't wish to limit the
mechanisms available to implementors of persistence, but the current
language definition does contain hoops through which persistent
implementations must jump.

  Certain requirements that must satisfied by some persistent object
systems, e.g., type evolution, are more significantly more difficult to
satisfy using the virtual function approach.  (Type evolution, i.e.,
changing the definition of a class after instances and modifying the
already saved instances as appropriate, may be substantially easier if
translation between computational and stored formats is done by
functions operating on the class, rather than functions of the class.)
That is, if an instance saved using an out of date definition is read,
either the read must fail or the instance must be translated into the
current definition.  I believe this implies something outside the class
must understand how the class changed, which a member function may have
difficulty doing.

  A number of C++ OODB efforts implement translation using mechanisms
other than member functions.  Some do not implement translation at all.
Of the persistent C++ implementations using the virtual function
approach that I know about, all seem to be "one of" systems, by which I
mean they do not seem intended as general solutions to persistence for
C++.  Indeed, some developers of such solutions now regret taking that
approach, arguing that a more general approach should be used.  Many
took the "virtual function does the work" approach because, at the time
they did their initial design, nothing else was available.

  Solutions to the persistence requirement that don't implement
translation using member functions need some way of identifying the
type of the object being translated.  Over the last few years my group
explored several approaches, including a preprocessor that generated
member functions returning type information with a version specifier,
and a preprocessor that enhanced "new" with a call to update a type
table.  We've also reviewed the member function-based implementations
of Interviews, and similar systems.

  I see the need for a standard mechanism for accessing a class
instance's type.  I believe a general mechanism, similar in spirit to
the property lists found in Lisp, would support not only type
information, but the needs of other enhanced facilities such as
programming environments.  I'd like to see the compiler insert into
each class a static member function that returns a pointer to a singly
linked list of pointers to a class instance.  The class pointed to
would have defined only a virtual function returning a descriptor.  The
descriptor would describe the sort of information the actual instance
contained, e.g., a description of a type.  Users would be able to
derive from the language-specified class description expanded classes
to support 
        * type information at various levels of detail, e.g., a
          compiled form for translation purposes and a source form for
          browsers; 
        * "wrapper" methods (like Lisp's before and after methods);
        * evolution methods, which accept an instance created using a
          previous definition of a class and return an instance usable
          under the current definition;
        * location information if the actual instance is not located in
          the current address space, to enable transparent forwarding in 
          a distributed environment;
        * references to source code, e.g., file name or memory address,
          for use by a programming tool such as Saber C++ and
          Objectworks for C++;
        * etc., etc., etc.  
There would be some cost, probably on the order of one null pointer
per class, if the facility isn't used by a particular application.

>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
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