Boost logo

Boost :

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?

Module/package dependencies.

> 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
> goal.

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, gregod at, cpdaniel at, john at