From: stephan b. <st...@ei...> - 2003-10-13 09:20:19
|
On Sunday 12 October 2003 11:38, Rusty Ballinger wrote: > The main thing which makes me unsure that this is a feature is, if > you have a Serializable class, you know exactly where to look for the > serialize() and deserialize() code, because the API tells you. (And > doxygen etc. will document this for you.) It sounds like with the > template version, you still need methods which have the same > semantics as serialize() & deserialize(), but now they can be called > something else, and you have to look at the template instantiation to > find out what their real names are? To touch on this, here's a snippet from the manual: Important Concept: thinking of others Despite common coding practice, and even perhaps common sense, client Serializables should not (for reasons of form and code reusability) call their own interfaces' de/serialize() methods directly! Instead they should use the various de/serialize functions in s11n_node. This is to ensure that interface translation can be done in s11n, allowing Serializables of different ancestry and interfaces to transparently interoperate. It also helps keep your code more portable to being used in other projects which support s11n. There are exactly two known cases where a client Serializable must call it's ancestor de/serialize() methods directly, as opposed to through a proxy: as the first operation in their de/serialize() implementations. In those two cases it's perfectly acceptable to do so, and in fact could not be done any other way. Any other usage can be considered "poor form" and "unportable." If you find yourself directly calling a Serializable's de/serialize() methods, see if you can do it via s11n_node instead (tip: you can!). In theory you can help enforce this concept by making your interface methods protected and making s11n_node and serializable_adapter<> friends of your class, but this is untested. -- ----- st...@ei... - http://www.einsurance.de "... NOT because we are America's poodle ..." Tony Blair, 30.9.2003 |