what are guidelines for when to split a module into a package?
Timothee Cour
thelastmammoth at gmail.com
Thu Feb 22 08:10:11 UTC 2018
> that doesn't help anyone who's actually reading the documentation and trying to find stuff that way
how about the following fix for that:
having a DDOC token on a package.d to indicate merging the submodules
in the documentation, eg:
```
/// MERGE_SUBMODULES
std/aglorithm/package.d
```
when user browses to https://dlang.org/phobos/std_algorithm.html, he
would see the DDOC contents from all direct submodules of
std/aglorithm/ right there in that ddoc page.
On Thu, Feb 22, 2018 at 12:04 AM, Timothee Cour
<thelastmammoth at gmail.com> wrote:
>> it actually does reduce compilation times if the imports go directly to the module in
> question rather than to a module that publicly imports the symbols
>
> time1=compilation time of `import std.algorithm : find;` before split
> time21=compilation time of `import std.algorithm : find;` after split
> time22=compilation time of `import std.algorithm.searching : find;` after split
>
> my understand is that we have:
> time22 < time1 but time21 ~= time1
> so we're in no way worse than before the split
> unless time21 > time1 (noticably) in which case you have a strong argument
>
>
> On Wed, Feb 21, 2018 at 11:57 PM, Jonathan M Davis via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Wednesday, February 21, 2018 23:48:32 Timothee Cour via Digitalmars-d
>> wrote:
>>> ```
>>> import std.algorithm.searching : find;
>>>
>>> not
>>>
>>> import std.algorithm : find;
>>> ```
>>>
>>> that's just a missed opportunity to benefit from the split; we're in
>>> no way worse after the split than before the split in that regard. We
>>> can just leave it as `import std.algorithm : find;` with no adverse
>>> effect.
>>
>> Maybe, but the CI stuff for Phobos doesn't like that, and it actually does
>> reduce compilation times if the imports go directly to the module in
>> question rather than to a module that publicly imports the symbols.
>>
>> - Jonathan M Davis
>>
More information about the Digitalmars-d
mailing list