Dave Abrahams wrote:
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 use other libraries in the implementation. These implementation details are generally not directly accessible by the library user. Any code injection/enhancement would be something that users would see in library portability, performance, robustness etc. It's my job to ensure that that is what happens. Actually, you've hit the nail on the head here. Chaning boost::throw_exception injects a dependency on a whole other boost library into the serialization library. And of course this is the crux of my complaint.
Of course it was. Do you think the problems with boost::throw_exception were intentional?
I'm sure the changes were intentional. I think the dispute is about whether those changes are problems (my view) or useful features whose value far exceeds any side effects of the changes (other's view) that.
But surely you do change existing headers from time-to-time?
only to a) fix bugs b) re-implement some existing interface c) add some new feature to the serialization library d) improve robustness, portability, etc. note that this above list does not include changing the functionality corresponding to some already existing interface - which is what we're talking about here.
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."
well, boost::throw_exception(x) wraps the x in some other class with some other stuff and does a throw. The serialization library does't use this. In order do this, I has to include some headers from boost exception. I've labeled this "code injection". Maybe it should have been "dependcy extension" but not the less I don't think I've said anything misleading..
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.
In this example the choice is clear. Either add suport for compiler X at the cost of increasing the code base or leave compiler X unsupported. And as the person responsable for the serialization library - I need to have the authority to make this decision. In this case the decision was made for me and didn't really evaluate all the concequences. This is no surprise because changes like this have a much larger ripple effect that first meets the eye. This has been my principal objection from the begining. Take the pottery barn rule: "if you break it, you bought it" this seems reasonable. Hence the following must be true: "If you're not prepared to buy it, don't risk breaking it!" So, unless one is prepared to take responsablity for the consequences, to muck with some other library.
We have a plan that's less ad-hoc than the last one?
There are number of other libraries which have implemented the same work around that the serialization library has - presumably for similar motivations. Each of these has been specified in it's own namespace. We're considering consolidating these into one header in the boost namespace/directory to put all these work arounds in a single place. Basically this would give a new name to the original boost::throw() functionality.
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.
lol - could be. but it's not as easy as it looks. I'll try. Robert Ramey