|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-11-27 12:27:54
"Peter Dimov" <pdimov_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk