🚀 go-pugleaf

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     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin