Subject: Re: [boost] [modularization] Extract xml_archive from serialization
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-09-17 07:23:44
Thanks for the response.
It's unfortunate the you provide so much stop-energy.
Robert Ramey wrote:
> I think the notion of "dependency" is richer than can be captured in this
> sort of graph.
No one claimed the graph was some kind of universal all-encapsulating
representation of "dependency *inverted commas*!".
> So it can't
> be understood in terms of this graph alone.
The graph is showing public module dependencies. I think that's understood.
> Consider another simple case - date time/serialization.hpp
> most date/time users don't use this - but a few do. Is serialization a
> prerequisite for date/time? which users are we talking about? One can't
> win here. If you distribute serialization with every use of date/time
> you're distributing too much. If you don't, you'll be failing to ship
> functionality which some users need. What is the solution here - make two
> libraries out of date/time? or what?
The solution is to make serialization low-cost to depend on, so that
depending on it is not a problem. That is exactly what I am recommending.
The current problem with serialization is that it is expensive in terms of
needless dependencies. My recommendation does a lot to solve that for
> So the graph tells us something, but what?
> So - the degree of "modularization" cannot be determined or illustrated or
> measured by examining the graph above.
> So, taken to it's logical conclusion, extracting xml_archive would lead to
> extracting other components as well.
Nope. No one has suggested that. Extracting xml_archive isolates the spirit
dependency. There is no similar motivation to extract other parts. I looked
a little bit into splitting all of the archive parts away from the
serialization part, but that still ties all the rest of the archive parts
needlessly to spirit.
What I recommend isolates the cost of spirit to the code that uses it.
There could be reason to try to split the rest of the archive stuff from
serialization, but I didn't look into that, so I'm not recommending it.
> Traditionally, (and not just in boost) libraries have been organized
> around developer responsibility.
What I recommend doesn't change anything of this.
> But the real questions are:
> a) what do we want modularization to accomplish and is this a feasible
This is where you are providing a lot of bad stop-energy. Were not these
questions answered years ago?
Tell me this: Why did boost migrate away from svn to 100 fractured (not
modularized!) git repos?
> c) Do we want to support deployment of boost subset? I think we do.
This question was answered years ago.
Why did boost migrate away from svn to 100 fractured (not modularized!) git
> My basic point is that these questions have to be addressed before the
> notion of decoupling can be carried much further.
Insisting that they are not already answered is not helpful.
> In concrete terms - the exclusion of xml_archive should be:
> a) dropped altogether - (find by me btw)
FYI, "fine by me" is what you say when you agree with a proposal. Here you
state the opposite of the proposal and say it's "fine by me" with a typo. It
is a very strange way to express yourself.
> b) created as a separate library module
This is the proposal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk