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
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
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
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
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
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
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
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
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
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
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
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
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