From: Robert Ramey (ramey_at_[hidden])
Date: 2008-06-09 13:32:20
My question has been and still remains:
Suppose that one has serialization specified for all his classes. He can
now serialize to any archive classs. Now he says - oh someone wants
YAML - use that - Damn. Using this one archive requires that I go back
and change the serialization of all my classes to support this one
archive. This imposes special requirements on serializable types for
a particular archive class - Thus coupling two concepts where
great effort has been expended to maintain them as orthogonal.
How can this be considered acceptable?
Then there is the question of what is a "primitive" in this context.
std::string is not a prmitive in the C++ sense, but it has the
serialization type trait set to "primitive". What about arrays?
they are built in types - but are they primitive. I don't want
the answer to these questions - I want to know that I don't have
to think about them in order to use serialization.
Oh then there is the question as to what the external class name
really is. Does it include the name space? What of it doesn't
and the program depends on "using" declarations to find it?
what about nested classes? does the name include all the
stuff its nested in? How are class names kept unique.
This opens up a whole other can of worms. Again, please
don't answer this question - the answer is not important. The
problem is that the question even has to be asked.
Finally - What does YAML even need a class name for?
Especially in light of the above.
I would guess that if YAML needs anything, it would be some
unique class identifier. perhaps you might consider the class
ID - maybe enclosed in quotes.
Natually, discussion of all the above issues has to be
part of the documentation.
Esteve Fernandez wrote:
> El Lunes 09 Junio 2008 18:36:53 Robert Ramey escribió:
>> My original question about this still stands:
>> This would seem to mean that the YAML serialization would require
>> for some types - but not for others. This would mean that YAML
>> archive would not
>> be substitutable for other archives - which defeats a large part of
>> the utility of the archive concept.
>> This is the interesting question here.
> Only classes need to be exported. Primitive types (such as int,
> float, etc.) and strings don't require BOOST_CLASS_EXPORT
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk