Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-06-15 11:48:17

On 06/15/2014 05:16 PM, Paul A. Bristow wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Peter Dimov
>> Sent: 15 June 2014 12:46
>> To: boost_at_[hidden]
>> 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