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
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk