Re: [boost] [modularization] Extract xml_archive from serialization

Subject: Re: [boost] [modularization] Extract xml_archive from serialization
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-09-17 07:23:44

Hi,

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

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

Disputed.

> 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 
repos?

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

Thanks,

Steve.