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: <27D56A26.2881@tct.uucp> Date: 6 Mar 91 22:16:05 GMT References: <1991Feb27.154311.782@csc.ti.com> <27CD159D.6581@tct.uucp> <1991Mar5.143615.5847@csc.ti.com> Organization: Teltronics/TCT, Sarasota, FL Lines: 35 According to peterson@choctaw.csc.ti.com (Bob Peterson): >Virtual functions are not the only foundation on which to build >persistence. Quite. "There's more than one way to do it." [tm] Larry Wall. >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. >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. What is wrong with the simple "ClassName:version"? >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. -- 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