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: <1991Mar5.143615.5847@csc.ti.com> Date: 5 Mar 91 14:36:15 GMT References: <27C95D3A.1715@tct.uucp> <1991Feb27.154311.782@csc.ti.com> <27CD159D.6581@tct.uucp> Sender: usenet@csc.ti.com (USENET News System) Organization: TI Computer Science Center, Dallas Lines: 98 Nntp-Posting-Host: choctaw 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 , >"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