"Peter Dimov" <pdimov@mmltd.net> writes:
Even if it did work, I don't see in which circumstances a class author would like to _not_ take advantage of the save_array enhancement. Ideally, he should just call save_array in save, without restricting it to a specific set of archives. I don't see what you gain by denying him this opportunity - assuming that it can be provided without negative consequences for the current code base or existing archive formats.
While I agree with this argument, it's been made more times than I can count, to no avail. I don't see why it should succeed this time, even coming from you. It seems to me it can only make Robert feel more beleaguered. I'd really like to remove the pressure from Robert to do what the rest of us think is best so that he can consider the following (quoting myself): If Robert insists [on a non-intrusive design], he is also buying into a situation where this function in the add-on library has to be used by every serialization function that _might_ be used in a performance-critical context, and every archive choice made in what _might_ be a performance-critical context must come from the add-on library, if an appropriate archive exists there (I am thinking e.g., of binary archives that would be present in the add-on library while text-based archives probably would not). That's what I want him to think about. If he understands what that means and prefers to avoid intrusion on the library design anyway, Matthias and I are willing to accept that and never bring it up again. After three years of hammering on this one point I can't blame Robert for being tired, and I have no reason to believe new arguments are likely to change his mind about it. Robert, I am happy to elaborate on the first paragraph if you still don't understand what I'm talking about. -- Dave Abrahams Boost Consulting www.boost-consulting.com