Re: [boost] [modularization] spirtit -> serialization

Subject: Re: [boost] [modularization] spirtit -> serialization
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-06-15 08:16:21

On 06/15/2014 01:40 PM, Andrey Semashev wrote:
> On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
>> Le 15/06/14 12:48, Andrey Semashev a écrit :
>>> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
>>>> Le 14/06/14 18:34, Stephen Kelly a écrit :
>>>>> Vicente J. Botet Escriba wrote:
>>>> Yes, and I propose to create a date_time.serialization submodule that
>>>> breaks the date_time -> serialization dependency.
>>>>
>>>> date_time.serialization -> date_time serialization
>>>
>>> The approach of extracting glue headers to separate submodules is not
>>> scalable. We have many other libraries using the same approach to optional
>>> dependencies.
>>
>> Why?
>
> Because it creates lots of tiny submodules, which creates maintainability and
> usability problems.

Optional files with additional dependencies need to be considered as 
independent nodes in the dependency graph, and thus allow us to 
understand how to remove undesired dependencies and potential for 
cycles. If that is agreed, then the rest is a question of how to achieve 
all that with tools.  For the proposed

date_time.serialization -> date_time serialization

building, deploying and using data_time no longer require serialization, 
unless you actually are using date_time.serialization in your source 
code at least.  The fact that the source comes along in the date_time 
git repository is not a concern as long as it is reasonably inexpensive.

>> I don't see why I would depend on Serialization if I don't use it
>> even if I use DateTime. IMHO, it is up to the client of the
>> serialization of the DateTime types to use the DateTime.Serialization
>> sub-module.
>
> You are right to desire not depending on Serialization if you don't use it.
> But this should not be achieved with submodules, IMHO.

Having these optional files in separate sub-module directories within a 
library modules git repository, is just part of one potential solution. 
  There may be other ways, do you have anything else in mind that scales 
better?

Using the term module, or sub-module, about nodes in the dependency 
graph make sense as what I think we attempt is modularization.  However 
the term sub-module is somewhat misleading as they conceptually are just 
as much independent modules as the top level git repository (Library) 
module.  But I guess a sort of maintenance ownership is reflected by a 
module being a sub-module.

Sub-modules such as optional headers could also be, "as-is", files more 
embedded into the "parent" module file structure .  However that may 
make it harder for tools to deal with the dependencies.

--
Bjørn