[serialization] implementing class_name_optional_type
Hi all, I'm working on the "YAML archives for Boost.Serialization" GSoC project and I've already implemented a working output archive. However, since YAML requires the class name to be always serialized, I had to implement the serialization of a new type called class_name_optional_type in basic_oarchive.cpp, which lets the archive decide if class names should always be written. It was discussed in the past [1], but never implemented, AFAIK. Cheers. PS: should I send the patch to this list or is it better to create a new ticket? 1 - http://lists.boost.org/boost-users/2006/06/20319.php
Hmmm - where does this class name come from if the class isn't exported? Would this mean that to make YAML archive, all class names MUST be exported? What about primitives like "int", do they need class names as well? I would guess this needs more thought. Robert Ramey Esteve Fernandez wrote:
Hi all, I'm working on the "YAML archives for Boost.Serialization" GSoC project and I've already implemented a working output archive. However, since YAML requires the class name to be always serialized, I had to implement the serialization of a new type called class_name_optional_type in basic_oarchive.cpp, which lets the archive decide if class names should always be written. It was discussed in the past [1], but never implemented, AFAIK.
Cheers.
PS: should I send the patch to this list or is it better to create a new ticket?
1 - http://lists.boost.org/boost-users/2006/06/20319.php _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
El Lunes 02 Junio 2008 18:13:22 Robert Ramey escribió:
Hmmm - where does this class name come from if the class isn't exported?
Would this mean that to make YAML archive, all class names MUST be exported? What about primitives like "int", do they need class names as well?
All class names must be exported (except for primitive types). Right now, class names are serialized only if they describe polymorphic classes. Cheers.
Hi all El Lunes 02 Junio 2008 12:31:38 Esteve Fernandez escribió:
PS: should I send the patch to this list or is it better to create a new ticket?
Joel (my mentor) told me to post the patch here. As you can see, it's not complete, as the oarchive part is implemented, but not the iarchive one. I'm sending it to know if I'm on the good track. Cheers.
My original question about this still stands: This would seem to mean that the YAML serialization would require BOOST_CLASS_EXPORT 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. Robert Ramey Esteve Fernandez wrote:
Hi all
El Lunes 02 Junio 2008 12:31:38 Esteve Fernandez escribió:
PS: should I send the patch to this list or is it better to create a new ticket?
Joel (my mentor) told me to post the patch here. As you can see, it's not complete, as the oarchive part is implemented, but not the iarchive one. I'm sending it to know if I'm on the good track.
Cheers.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 BOOST_CLASS_EXPORT 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 Cheers.
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 additional 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. Good Luck. Robert Ramey 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 BOOST_CLASS_EXPORT 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
Cheers. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
El Lunes 09 Junio 2008 19:32:20 Robert Ramey escribió:
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 additional 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.
But, doesn't the XML archive force you to change your serialization as well? I mean, you need to serialize every member with BOOST_SERIALIZATION_NVP. If I serialized my objects with the text or the binary archives, I would have to change their serialization if I wanted to use the XML archive.
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.
Sorry if I didn't explain myself properly. Maybe it's a bit easier with an example, here's an object serialized in YAML with pyyaml: !!python/object:namespace.A a_string: some string an_int: 0 an_object: !!python/object:namespace.B a_float: 3.14 I know that Boost.serialization doesn't try to deserialize any kind of document, even if it's well formed. "Boost.serialization only (de)serializes Boost.serialization documents" has become my mantra :-) I can replace those !!python/object:namespace.{A,B} with !!boost/object:class_id_{0,1} in the worst case, but would prefer to expose class names if I can.
Natually, discussion of all the above issues has to be part of the documentation.
Good Luck.
Thanks for taking the time for explaining all this. It was very constructive, really. Cheers.
Esteve Fernandez wrote:
But, doesn't the XML archive force you to change your serialization as well? I mean, you need to serialize every member with BOOST_SERIALIZATION_NVP. If I serialized my objects with the text or the binary archives, I would have to change their serialization if I wanted to use the XML archive.
well, that's a good point. However, using BOOST_SERIALIZATION_NVP doesn't have any side effects but BOOST_CLASS_EXPORT does. We've only recentlly got handle on all the implications of the "export" facitity. I'm still not getting he issue about the prmitives - that is, even if we made this change, you'ld have the same problem with primitives. That is some items would have class names and others wouldn't. Perhaps you might consider using the class_id but use the name if it has been exported. Then it would always work. Anyone unhappy with the ids could turn around and export all his class names. Robert Ramey
El Martes 10 Junio 2008 02:31:06 Robert Ramey escribió:
I'm still not getting he issue about the prmitives - that is, even if we made this change, you'ld have the same problem with primitives. That is some items would have class names and others wouldn't. Perhaps
Sorry, I don't see where's the problem with the primitive types, YAML doesn't need the class name for these types. Strings, arrays, lists, maps and primitive types (int, float, double, char) are native YAML types and are serialized "as is".
you might consider using the class_id but use the name if it has been exported. Then it would always work. Anyone unhappy with the ids could turn around and export all his class names.
That's a good option, but it needs class_name_optional_type. Do you think my patch looks good? If you think class_name_optional_type should be implemented, I'll provide a patch for input archives as well. Cheers.
participants (2)
-
Esteve Fernandez -
Robert Ramey