on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development.
Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI?
No. I don't do this.
I believe you mean that sincerely, but I just don't see how it's possible for you to know that. Do you keep track of exactly which of Boost.Serialization's headers is being used by every dependent Boost library and make sure that *no* new capabilities creep into any of those headers as you extend/evolve the library? Even if you _can_ do that for other Boost libraries, you can't possibly do it for your users.
I have made some mistakes - particularly in the implementation of binary_iarchive which have broken other peoples code. But I assure you this was totally unintentional.
Of course it was. Do you think the problems with boost::throw_exception were intentional?
This wouldn't mean that no new code is never added. Natually one could add a new archive type. But that would only affect those who conciously chose to use it.
Yes, if you never touch existing headers, you will never cause such a situation. But surely you do change existing headers from time-to-time?
But that would of course that be a different case.
Don't you expect the author of type_traits to do the same thing?
No. I don't.
If I use something like "is_arithmetic" I expect it's functionality to not change in the future.
That's not at all like what you said happened. Sure you would expect is_arithmetic to remain the same. What you said was that "new bodies of code" were "injected" that "add no functionality used/needed by Boost.Serialization." We did that to type_traits when we upgraded it to work more smoothly with Boost.MPL. Changes like that are rare, but changes like this one aren't: The maintainer of is_arithmetic makes changes to support compiler X. Boost.Serialization does not support compiler X. Therefore these changes "add no functionality used/needed by Boost.Serialization." Such changes might be arbitrarily complicated, including pulling in new header files.
I'm happy to move on if you're really going to put this behind you. If you won't truly be able to, then we should keep talking until we can all understand each other because this is at least the 2nd time we've had a long argument about it and it would be a shame to have to go over the same ground again.
I'm sympathetic to you view here. It wasn't really resolved before - we just worked around it. Basically this is what we're going to continue to do albeit is a less ad hoc way.
We have a plan that's less ad-hoc than the last one?
I'm really sympathetic to those who see this as a pointless, endless argument.
I'm not among them. I'm just trying to do everything possible to ensure that this time around the argument is point-ful.
But obviously it's not for those of us involved in it. For the most part I don't doubt the good intentions and sincerity of those who are disagreeing with me here. I just think they're wrong and they they have failed to make a convincing argument that I'm wrong. And I believe that these "wrong ideas" (my view) make a large negative impact on software usability and quality.
Some of us are arguing with you because we respect your opinions on these matters, but aren't able to see the "wrong ideas" you've been pointing at. Arguing is a way of probing for enlightenment. My guess so far is that you have something real in mind, but you're not expressing it with enough precision for others to grasp it. I think it might help if you could make an effort to be extremely concise, so your point is in a non-TL;DR context. If you use very few words it should be very obvious to you whether they'll communicate what you actually mean to say. -- Dave Abrahams BoostPro Computing http://www.boostpro.com