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