$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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