🚀 go-pugleaf

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     <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