Re: [boost] Moving files around

Subject: Re: [boost] Moving files around
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-10 10:19:02

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