🚀 go-pugleaf

  I should point out that for purposes of this discussion I assume an
OODB in which changing a class instance to conform to a revised
definition is done "as needed," rather than "all at once," or batch. 
In the latter environment a utility would carry out the changes, all
programs impacted are immediately recompiled, and the issue of runtime
type information becomes moot.

  Also, almost the same set of issues arise when considering movement
of a class instance into or out of an address space, including movement
for persistence and for interprocess communication.

In article <27D56A26.2881@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to peterson@choctaw.csc.ti.com (Bob Peterson):
>>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.
>
>I am not persuaded that this conclusion is necessary.  _Something_
>must know about the changes; why not the class itself?  In other
>words, what is the difficulty with giving to each class the
>responsibility for remembering its own revision history?  I'd like to
>hear specific technical problems.

  Technical problems arise in several areas.  The first two are hard
issues, while the second two seem easier to solve.

  * Certain properties of an object's representation depend on the
specific runtime environment.  Examples include 
	the implementation details of virtual functions,
	the implementation details virtual inheritance,
	how ordering of the names of inherited classes impacts the 
	    layout of local and inherited member variables,
	how the compiler chooses to order the noncontiguous parts 
	    of the class' state, and
	where and how much padding is inserted to obtain correct
	    alignment.
Translating from external format to internal format must take all of
these factors into account.  Any of the above can change without
changing the meaning of a program, and, quite correctly, the language
definition excludes specification of any of them.  Do we wish to
require the class implementation to understand all possible
implementations of the above properties, past as well as present?  I
believe such details, which are not part of the language, should not be
reflected in the class.  They must be taken care of outside the class,
i.e., by an external translation mechanism.  (I do assume we expect the
class itself to be portable, as well as instances of the class.)

  * Certain kinds of type evolution occur outside the immediate class.
Examples of such changes include changing an ancestor class's
inheritance list, and changing from ordinary to virtual inheritance. 
While such changes can alter the immediate class's state, forcing
recognition of the change in the immediate class may be undesirable.
For example, a class should not care about insertion of an additional
privately inherited class in an ancestor.  Forcing such recognition
could easily result in substantial maintenance, an effort not required
if a different approach is used.

  * If I need to add a class library to my development environment I
must somehow add the appropriate translation methods to the library. 
This implies I must have source code.  If instead of using methods, the
system derives translation data from header files, I _might_ be able to
use a binary distribution of the library.  Requiring source code
changes precludes using a library available to me only as a binary.

  * How many prior versions must a class know about?  In the real
world, the number of revisions will certainly be larger than one, and
could easily exceed 20 over the lifetime of a database.  As revisions
accumulate the evolution function(s) embedded in the class will become
large.  (This isn't really a technical problem, but a management
problem, I confess, but I believe it is relevant.)

  For a good discussion of over 20 ways to change a class, and the
meaning of each change, see "Semantics and Implementation of Schema
Evolution in Object-Oriented Databases," Banerjee & Kim, Proceedings of
SIGMOD 1987, pp. 311-322.  While the paper discusses a Lisp-based OODB,
it is quite relevant to C++ class evolution.  About one quarter of the
changes in their list do not show up in the immediate class.

>>I see the need for a standard mechanism for accessing a class
>>instance's type.
>
>I fail to see any benefit such a feature would provide for
>persistence, since other information essential for freezing an object
>(private member variables, for instance) will be unavailable from the
>outside.

  Why do you assume the absence of a data dictionary?  In fact, most
existing OODB implementations use a data dictionary, i.e., a complete
description of all data stored in the database.  Frequently a utility
program initially loads the dictionary from information in header
files.  That same utility should be able to detect changes in a class
definition, no matter what the origin of the change.

  More advanced dictionaries support browsing of the definitions. 
Future dictionaries will feature interactive interfaces.  Developers
will make class changes through the dictionary, with interactive
support for visualizing the impact of the changes, as well as
dictionary support for ensuring the changes reflect correct semantics
and are supportable by the translation mechanism.

  Given a data dictionary, when an application runs and fetches an
object saved using a now out of date definition the OODB runtime can
consult the dictionary to figure out what changes must be made in order
to correctly utilize the object under the definition known to the
application.  The OODB runtime may alter the translation of the
object's state, providing default values for added data members,
connecting as appropriate to the language's virtual function mechanism,
etc.  

>-- 
>Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
>   "All this is conjecture of course, since I *only* post in the nude.
>    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre

    Bob

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