Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <27DBCA6C.57EB@tct.uucp> Date: 11 Mar 91 18:20:28 GMT References: <1991Mar5.143615.5847@csc.ti.com> <27D56A26.2881@tct.uucp> <1991Mar8.142744.8303@csc.ti.com> Organization: Teltronics/TCT, Sarasota, FL Lines: 75 According to peterson@choctaw.csc.ti.com (Bob Peterson): >In article <27D56A26.2881@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>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. > > * 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, > ... > Translating from external format to internal format must take all of > these factors into account. But these issues shouldn't enter into the discussion at all! Any implementation of persistent objects for C++ will presumably be designed to require no more of its environment than the presence of a C++ language compiler/interpreter. In particular, it will not need to know any details of the C++ implementation. For the persistent-object support to be aware of the details of a particular C++ implementation is, in my opinion, a design error. In any case, the C++ implementation details are not relevant to the question of how a virtual member function is at a disadvantage compared to a non-member function in freezing and restoring objects, which is what I asked about. > * 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. Such type evolution must be dealt with by any store/retrieve function, whether it be a virtual member function or some other kind. Realize that, as I envision it, the virtual functions for storage and retrieval will be generated automatically from the data dictionary. That same data dictionary will also be used to generate the C++ class definition. Internal and external type evolution are handled equally well by such a system. > * 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. Yes -- iff you desire to create persistent objects of library-defined types. I would avoid this need by (1) getting source code, which IMHO is vital for C++ programming anyway, or (2) creating persistent classes that contain or derive from the library-defined classes. > * How many prior versions must a class know about? ... As revisions > accumulate the evolution function(s) embedded in the class will become > large. True but irrelevant to the virtual-vs.-friend issue. >> ... 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, I did assume a data dictionary for my approach described earlier. I just didn't think of it when I wrote the above sentence. >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. To suggest that information and procedures of this kind belongs anywhere _except_ the class definition is, IMO, preposterous. -- Chip Salzenberg at Teltronics/TCT , "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin