Joaquín Mª López Muñoz wrote:
As I see it, the helper interface does not litter the serialization code, it merely provides an extension API for users implementing non-trivial serialization schemes --note that the helper themselves are not part of B.S but belong in the different serializable types, much like the associated serialize() functions.
I didn't really see this. In large part due to the fact that no one over the years as expressed a need for it. The only reason I had to add it was to accomodate design issues with smart_ptr which makes it impossible to serialize without special help. So I always considered it a pathalogical case.
With all due respect (and admiration for your great lib) I think the mix-in idea has many flaws as compared with the former helper interface. Let me state several points supporting my thesis and addressing some of the claims you make above; I'd be grateful if you could discuss them with me:
First of all, let me say its always a pleasure to disagree with you.
1. You state that the mix-in approach "doesn't change the published API of B.S". I don't think so: if I decide to implement an Archive type I must explicitly handle shared_ptr (or decide not to do it, I guess this is what your naked_* archive versions are for), so definitely this shows through the API I'm expected to implement.
For that one case. I understand the situation, but as I said I felt that was an (almost) unique situation.
2. Having an ad-hoc extension for one particular type seems to me a recipe for disaster. Consider the following: some environments are already providing std::tr1::shared_ptr, which of course does not have built-in serialization capabilities. How am I supposed to serialize this? Are you going to add another mix-in to your Archive classes to handle this as well?
I haven't made any plans. Even the runtime helper, I would still have to make special code for a new shared_ptr - so its just a question of where the code ends up.
3. You say that adding mix-ins is equivalent to adding helpers, but I think the approaches are radically different. Addition of a mix-in is a. made at compile time b. part of the implementation of the archive while addition of a helper is a. made at run-time b. part of the serialization code for a type Mix-in are closed for extension where helpers are open: If I need a helper for serializing some T and I'm using an Archive whitout special support for that T, all hope is lost.
4. IMHO the helper API in B.S 1.34 is a simple yet powerful capability, and does not look forced or clumsy at all. It simply provides a way to add state info to an archive object, which is in a sense a state machine transtitioning its way during the serialization process. I contend that helpers allow for implementing serialization for types which otherwise would be impossible to serialize or should rely on inefficient detours: a. boost::shared_ptr (unless adhoc provisions are made) b. std::tr1::shared_ptr c. STL containers iterators. d. The lib I'm writing, which is the original cause why I started this thread, provides a class called flyweight<T> where flyweights with the same value share their representation by holding internal pointers to the same T value. Serializating this is trivial with the aid of a saving helper that maps T*s to flyweight<T>s --without helpers, the best I can come up with involves T duplication in the serialization stream and inefficient creation of flyweights on saving time.
As, I've said, based on experience so far, I've been of the idea that the only case where one would ever need this is shared_ptr. So we can think about this. Lately I've become more focused on improving performance of the serialization library and this provided part of the motivation for eliminating helpers for those who don't need them. Another very significant issue was that making the helper concept official would mean that I would have to document it which would lead to people asking questions about it which would lead to people spending a lot of time telling me how it could/should be enhanced, and me responding, etc, etc, etc. So I was and still am interested in shrinking down the serialization library by factoring that which is orthogonal to serialization. Perhaps the best resolution is to just make a mix-in class equivalent to the previous helper functionality. It would seem to me that this would give you every thing we both need. Robert Ramey