RE: [boost] Serialization Submission version 6

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-10 12:29:42

-----Original Message-----
From:	Vladimir Prus [SMTP:ghost_at_[hidden]]
Sent:	Sunday, November 10, 2002 5:52 AM
To:	Boost mailing list; Robert Ramey
Subject:	Re: [boost] Serialization Submission version 6

Robert,

> I have just loaded the latest version of the serialization library (serialization6.zip)
> to the files section.
> 
> changes from previous versions include:
> 
> 1) A demo addressing the issue of plug-ins and global registration.  

I'm somewhat lost. To begin with, demo without a documentation is
only 50% helpfull (or even less). Second, it does not answer my
concerns. You seem to mean, that if I want to store classes by base
pointers, then I should roll my own registration system?

- Volodya

If you want to create archives that store classes through base class pointers
and the programs that read the archives can share the same header files
you will have to register the classes used.

In situations where the above is not possible, e.g. plug-ins, 
you must roll your own registration system.

After much thought on the questions you have raised I have come to 
conclude the following:

1) type_info is not portable
2) type_info can never be used as as a universal external type identifier
3) There is no automatic way of providing such a universal type identifier.

Arguments

1) type_info is not portable

This point of fact is made in all references so I don't believe this is in dispute. 

2) type_info can never be used as as a universal external type identifier

Suppose  type_info where made portable - For example, suppose that a string containing
namespace, class name, and base class names were used.  At first blush this might 
seem to work.  But the same class is used in another program in another
namespace so we better remove the namespace.  Hmmm now we could
have two classes with the same type_info id which are in fact different.  A serialization
system could not detect this difference and loading would fail.  Basically, accross
programs, class names are not guaranteed to be unique so any method of "matchiing"
classess across programs using class names or some derivative there of is
bound to be unsuitable for our purposes.

3) There is no automatic way of providing such a universal type identifier.

Suppose we use something stronger - e.g. the whole class declaration.  That should
be sufficent - Or is it?  First of all this wouldn't permit one to change class declarations
with out changing its "identity".  Hence newer class versions couldn't be matched
with older ones.  Class versioning (an indispensible concept) could not be implemented. 
Besides, the fact that two declarations might be identical in no way guarentees
they have the same implementations accross programs.  So the above still applies.

This leads to the conclusion that "class identity" cannot be resolved merely by
inspecting program header code - which is all the compiler can do.

I believe that it is for this reason that type_info was made "non-portable".  Trying to
make it portable would serve no useful purpose.

I also believe that this is the motivation for microsoft using GUID (Globally Unique Identifier)
for its "plug-in" implementation - COM (Common Object Model).  I don't know about CORBA
but I would guess it has some sort of analogous method.

In the Microsoft method, an  (18 digit?)GUID is generated on one's machine with a special program
guarenteed (to one chance in a very large number) in time and spaceto be unique. This
unique number is used by the programmer in all his programs that use a particular class.
That is, the concept of "class identity" is addressed explicitly by the programmer.
There is no automatic way to assign "class identity"

By the way, given the number of digits in thier GUID,  "unique in time and space" means
time(longer than the age of the universe) and space (whole universe).  No one has ever
accused Microsoft of lack of ambition.

End of argument

I am aware that the above argument might not convince you.  However you must concede
that someone might agree with me. 

My example factors out the "class identity" issue. 

If you believe, in spite of the arguments above, that you have a portable implementation of type_info
that can serve as a cross program class identifier, your free to use in the way the example does.
If not, you can use any "class identity" system you prefer.

This issue only occurs in "plug-ins" where classes need to be created by programs that don't have
access to the class headers of the derived classes. If your importing class header in each program
that uses your class, the whole issue is moot.  In this case, local class identifiers based on the
sequence that class members are "seen" by the serialization system are sufficient and work well
as experience of the many users of this system will attest.

If you find the requierment to "register" derived classes distastful, you can use the example
as a basis for your own local registration system.

This should make everyone happy.

Robert Ramey

P.S. I would be glad to add comments to the demo if its unclear.  I would might be willing
to include information such as the above in the documentation.  However, you seem to 
be the only person for whom this is a large issue.  So I wonder about the value of this.
RR