www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Circular dependencies in Phobos

reply tsbockman <thomas.bockman gmail.com> writes:
How important is it to avoid circular dependencies in Phobos?

I'm wondering because I have divided my work-in-progress 
std.checkedint module into various submodules to make it easier 
for people to import only the part they actually want to use.

However, most of these submodules depend at least a little bit on 
all the others. This comment by Walter Bright makes me wonder if 
the current layout would be accepted:

http://forum.dlang.org/post/n6alnb$226t$1 digitalmars.com

 Circular declarations are one thing, circular modules are 
 another. Phobos suffers from circular modules, and I'd like to 
 refactor them out.


Would my submodule scheme be likely to pass review, or should I 
just change it now?
Jan 03 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 15:46:55 UTC, tsbockman wrote:

 How important is it to avoid circular dependencies in Phobos?

 I'm wondering because I have divided my work-in-progress 
 std.checkedint module into various submodules to make it easier 
 for people to import only the part they actually want to use.


Splitting modules into a circular package retains *some* of the 
benefits of split modules, like the smaller namespace in 
importing modules: while the whole tree is recursively pulled in, 
the user chooses which symbols to make available in the importing 
module. In D we have a number of conflict resolution mechanisms, 
including selective imports, so I don't count this as 
particularly useful.

The real benefits come when the split modules form a clean, 
non-circular dependency graph. Then we get the good stuff like 
faster compile times and smaller executables, can be understood 
in chunks etc.

I'm personally not a fan of circular modules, but I don't have 
strong opinions about them. In Phobos we have a number of modules 
with poor granularity that could be split into clean dependency 
trees. I don't know what to do, if anything, about circular 
modules that *can't* reasonably be split up as such.
Jan 03 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 16:52:28 UTC, Jakob Ovrum wrote:

 In D we have a number of conflict resolution mechanisms, 
 including
 selective imports, so I don't count this as particularly useful.


That would be more helpful if selective imports weren't 
semi-banned at the top level:
     https://github.com/D-Programming-Language/dmd/pull/3407
Hopefully that will finally get merged before checkedint is 
ready...
Jan 03 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:

 That would be more helpful if selective imports weren't 
 semi-banned at the top level:
     https://github.com/D-Programming-Language/dmd/pull/3407
 Hopefully that will finally get merged before checkedint is 
 ready...


It's only a relevant issue for library code.
Jan 03 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 17:09:45 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:

 That would be more helpful if selective imports weren't 
 semi-banned at the top level:
     https://github.com/D-Programming-Language/dmd/pull/3407
 Hopefully that will finally get merged before checkedint is 
 ready...


 It's only a relevant issue for library code.


Surely checkedint should be usable from library code, though.
Jan 03 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 17:13:34 UTC, tsbockman wrote:

 On Sunday, 3 January 2016 at 17:09:45 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:

 That would be more helpful if selective imports weren't 
 semi-banned at the top level:
     https://github.com/D-Programming-Language/dmd/pull/3407
 Hopefully that will finally get merged before checkedint is 
 ready...


 It's only a relevant issue for library code.


 Surely checkedint should be usable from library code, though.


Yes, but it shouldn't be designed around a bug.
Jan 03 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:

 Yes, but it shouldn't be designed around a bug.


Unless the bug is actually going to be fixed some time soon, why 
would I deliberately design something in a way that is broken? 
Does it really matter *why* it is broken?
Jan 03 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:

 On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:

 Yes, but it shouldn't be designed around a bug.


 Unless the bug is actually going to be fixed some time soon, 
 why would I deliberately design something in a way that is 
 broken? Does it really matter *why* it is broken?


So, we're talking about a library using CheckedInt. If the 
library selectively imports anything from CheckedInt at 
module-level, it'll always be public due to a bug.

This is trivial to work around. Often the import can be nested, 
and when it can't, a static import or renamed module import can 
be used to resolve conflicts.

It's not a big deal.
Jan 03 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 17:31:41 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:

 On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:

 Yes, but it shouldn't be designed around a bug.


 Unless the bug is actually going to be fixed some time soon, 
 why would I deliberately design something in a way that is 
 broken? Does it really matter *why* it is broken?


 So, we're talking about a library using CheckedInt. If the 
 library selectively imports anything from CheckedInt at 
 module-level, it'll always be public due to a bug.

 This is trivial to work around. Often the import can be nested, 
 and when it can't, a static import or renamed module import can 
 be used to resolve conflicts.

 It's not a big deal.


Apparently the bug affects static imports and renamed module 
imports too. Bleh.
Jan 03 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 17:34:19 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 17:31:41 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:

 On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:

 Yes, but it shouldn't be designed around a bug.


 Unless the bug is actually going to be fixed some time soon, 
 why would I deliberately design something in a way that is 
 broken? Does it really matter *why* it is broken?


 So, we're talking about a library using CheckedInt. If the 
 library selectively imports anything from CheckedInt at 
 module-level, it'll always be public due to a bug.

 This is trivial to work around. Often the import can be 
 nested, and when it can't, a static import or renamed module 
 import can be used to resolve conflicts.

 It's not a big deal.


 Apparently the bug affects static imports and renamed module 
 imports too. Bleh.


Yes visibility control for the import system is pretty badly 
broken right now. I'm surprised this still hasn't been fixed 
after so long; I guess it must be really tricky for some reason.

Anyway, my submodule setup is motivated as much by the desire not 
to be forced to make long lists of every symbol I import, as it 
is by the need to work around that bug. If it was left up to me, 
my scheme wouldn't change that much even if the bug were fixed 
tomorrow.
Jan 03 2016
next sibling parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Sunday, 3 January 2016 at 18:41:39 UTC, tsbockman wrote:

 Anyway, my submodule setup is motivated as much by the desire 
 not to be forced to make long lists of every symbol I import,


Why are you forced to do that?
Jan 03 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 19:00:56 UTC, Jakob Ovrum wrote:

 On Sunday, 3 January 2016 at 18:41:39 UTC, tsbockman wrote:

 Anyway, my submodule setup is motivated as much by the desire 
 not to be forced to make long lists of every symbol I import,


 Why are you forced to do that?


Mostly because I deliberately reused some names from std.traits 
and std.conv.

When I upload the new version to DUB (some time later this week, 
I think) you'll be able to see why, if I haven't thought of a 
better scheme by then.
Jan 03 2016
prev sibling parent Meta <jared771 gmail.com> writes:
On Sunday, 3 January 2016 at 18:41:39 UTC, tsbockman wrote:

 Yes visibility control for the import system is pretty badly 
 broken right now. I'm surprised this still hasn't been fixed 
 after so long; I guess it must be really tricky for some reason.


There's been a pull request to fix it open for a long time now 
but nobody has merged it.
Jan 03 2016