Can I just fire a shot across the bows before we all get too carried away moving files around here there and everywhere? *The move has to make logical sense* - reducing dependencies is a worthy goal, but not if it makes stuff harder to maintain and/or harder for the user to find what they're looking for. Let me give you a trivial example: boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. OK fair enough. But I see no tests or docs, and the docs at the very least are still in "utility". So now we have a situation where maintenance of that functionality is split over two repositories each with different maintenance teams. That's not good. Perhaps more to the point, if I'm a user and I'm looking for boost/something/whatever.hpp, it had better darn well be in package "something" or I'm going to be pretty annoyed. This applies equally to folks wanting to use "whatever.hpp" as to folks wanting to submit pull requests. In fact if the above doesn't hold I suspect that a) Folks will give up and reinvent smaller utilities for themselves. b) Use an older version of Boost ("I new where everything was there"). c) Not submit bug reports or pull requests cause they can't figure out where they should go. I guess what I'm saying is that while re-factoring is a good idea, it needs a vision to improve "discover-ability" and make Boost's structure more logical, not merely easier for a package manager. Now please do carry on as you were ;) John.
John Maddock wrote:
boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. OK fair enough.
I could have moved it into core, but I didn't want to start adding type traits there until we've decided whether we're going to have some kind of "core type traits". Although, as things currently seem to stand, replicating a subset of the type traits in core, along with a "proper" core::bool_, looks like the only viable way forward. I still don't like that option much though. As for the general point of your post, yes, you're absolutely right. In fact, I would say that we should as a general rule no longer move headers around at all.
Le 10/01/15 11:28, John Maddock a écrit :
Can I just fire a shot across the bows before we all get too carried away moving files around here there and everywhere?
*The move has to make logical sense* - reducing dependencies is a worthy goal, but not if it makes stuff harder to maintain and/or harder for the user to find what they're looking for.
Let me give you a trivial example:
boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. Who did this move? Did I missed any post about this? OK fair enough. But I see no tests or docs, and the docs at the very least are still in "utility". So now we have a situation where maintenance of that functionality is split over two repositories each with different maintenance teams. That's not good. Agreed.
Perhaps more to the point, if I'm a user and I'm looking for boost/something/whatever.hpp, it had better darn well be in package "something" or I'm going to be pretty annoyed. This applies equally to folks wanting to use "whatever.hpp" as to folks wanting to submit pull requests. Agreed. If moved to another module, let say somethingelse, the file should be placed in boost/somethingelse/whatever.hpp, and the old file must just have a #include to the new file and a deprecated comment(pragma). The old file should be removed after let me say 3 versions.
In fact if the above doesn't hold I suspect that
a) Folks will give up and reinvent smaller utilities for themselves. b) Use an older version of Boost ("I new where everything was there"). c) Not submit bug reports or pull requests cause they can't figure out where they should go.
I guess what I'm saying is that while re-factoring is a good idea, it needs a vision to improve "discover-ability" and make Boost's structure more logical, not merely easier for a package manager.
Completly agreed. I think this is why we are discussing so long for any even minor change. Best, Vicente
participants (3)
-
John Maddock -
Peter Dimov -
Vicente J. Botet Escriba