On 06/15/2014 05:16 PM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 15 June 2014 12:46 To: boost@lists.boost.org Subject: [boost] date_time -> serialization (Was: spirtit -> serialization)
Vicente J. Botet Escriba wrote: Le 15/06/14 12:48, Andrey Semashev a écrit :
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? 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.
What others think?
I think that Vicente is right in this case. Moving serialization support to a submodule of DateTime will make the dependency report nicer _and_ it will actually be correct from the perspective of an automatic downloader. If you use DateTime, you'll get the DateTime repo, along with the serialization support, but you will not get the Serialization repo (and its dependencies) if you don't use Serialization. And this is exactly as it should be, unless I'm missing something subtle.
It seems to me that this is a legitimate use of sub-sub-modules.
I've followed this thread with interest and general support, but there is one factor that doesn't seem to be 'factored-in' in.
If someone is using Serialisation then isn't there a very high probability that they are also using DateTime?
maybe 20% is my best guess for that probability, but it is only a guess.
So having these in the same package doesn't really matter (except for the artificial level number)?
Would not that approach force all serialization users to depend on all modules that happens to have serialization support embedded in serialization module. How will that be better?
Looking at the shrink-wrap users, I have a suspicion that this applies quite widely - many people will manage to pull in a big chunk of Boost.
Rearranging the modules isn't going to change this much.
Sub-sub-modules sound Very Evil to me.
It does not sound all that good to me either, but they are just modules. So a better name may help with the "sound Evil" part.
KISS applies?
Yes, how are you proposing to keep it simple? -- Bjørn