Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!tilde.csc.ti.com!choctaw!peterson From: peterson@choctaw.csc.ti.com (Bob Peterson) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <1991Mar8.142744.8303@csc.ti.com> Date: 8 Mar 91 14:27:44 GMT References: <27CD159D.6581@tct.uucp> <1991Mar5.143615.5847@csc.ti.com> <27D56A26.2881@tct.uucp> Sender: usenet@csc.ti.com (USENET News System) Organization: TI Computer Science Center, Dallas Lines: 123 Nntp-Posting-Host: choctaw 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 , > "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