Neil Groves wrote:
This is a legitimate concern which IMO has not been taken seriously by the Boost community.
Why do you think this is not being taken seriously? I'm under the impression that there is disagreement as to the real priority of this concern. I think that is quite different.
I was specifically refering to the recent discussion of Boost Exception. I got "out voted" on that one which I characterized as having my "concerns not being taken seriously". If you prefer to say "disagreement as to real priority" I'm fine with that. I don't think we're disagreeing here.
To some extent it's unavoidable since it's more efficcient to have one "best" solution imported everywhere rather than replecating code.
But it doesn't have to be as bad as it currently is. And it's only getting worse as more libraries get added to Boost.
Again why is it 'Bad'? This is re-use in most examples I have seen. Coupling isn't inherently bad. Re-use is coupling.
OK - maybe 'bad' is the wrong word. As new libraries get added they depend on previous libraries. It's generally a good thing that code not be repeated. But it makes it more likely that a library user is importing stuff that might surprise him. This is unfortunate (bad) but unavoidable. It's "bad" when the library author includes surprising and or unnecessary dependencies. These bite the user with unexpected behavior like a) much bigger executables than expected b) new requirements like multi-threading c) breakage from updates of seemingly unrelated components.
Specific examples of poor coupling most probably exist. I suspect these would receive a good response from the Boost development community if these were specifically raised.
In many cases there is disagreement what "poor coupling" is.
Did you complain about them in trac tickets that have not been resolved?
This is not an issue regarding bugs. There are differences of opinion regarding library design and approriate functionality and requirements. This differences are reconciled as best we can through the review process.
b) Consider eliminating "convenience" headers.
I think the Boost library authors are good at choosing the right level of headers to include. Do you have some specific counter-examples?
I don't think that "convenience headers" all that bad. As a user, I'm free not to use them (and I don't). BUT - a) I think they encourage practices among users that I don't think are good ones. b) I don't think they are really necessary. The serialization library - a big library - has never had them and no one has ever asked for them. c) It's trivial for users to make their own if they want them.
I definitely took the approach of using convenience headers in examples. I did this because the header files were not the primary focus of the example code. The convenience header in my examples provides code that works while reducing clutter in my example.
d) I understand this. But I see it differently. If one has to use convenience headers to make the examples simple enough to understand, I would consider the possibility that the library might be made clearer and easier to use by refactoring the headers..
Perhaps instead we could provide additional guidance as to how to use the layers of header files.
I think that is one of the things I'm proposing here.
However this seems trivially obvious.
lol - then I guess it will be easy to agree on how to it Robert Ramey