Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?

Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-09-05 22:13:07

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