This is also how it's handled in Orange, every serialized value has a key associated with it. But currently it throws when it can't find something in the archive. I'm going to add an option for not throwing.
On 8 aug 2010, at 18:08, Michel Fortin wrote: > Le 2010-08-08 à 11:31, Andrei Alexandrescu a écrit : > >> Good point. This is not a template-specific problem; if you try to >> deserialize a derived class and the client doesn't know of that class... >> well there's not a lot one can do, unless you package the code of the >> methods with the object. >> >> I think it's reasonable to limit (at least for now) things to requiring that >> the client knows about the exact type serialized. And they need to have a >> layout-compatible version. Which brings us to a related problem - >> versioning... > > My preferred way to handle versioning is to not have to handle it. I > generally use key-value pairs to store the content of aggregates (structs, > classes). This means I can grow the number of members over time while keeping > backward compatibility. If a member is missing from the serialization I use > the default value or the class/struct can handle the case with a more > specialized behaviour. I can also continue serializing a no-logner necessary > value to keep the aggregate backward compatible with older code. > > This also makes things less fragile in regard to layout changes: you don't > need to keep variables in the same order on all platforms, in all versions, > etc. > > So that's how I've build my serialization module. I probably should stop > talking about it and finish it instead... :-) > > -- > Michel Fortin > [email protected] > http://michelf.com/ > > > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
