Reducing the inter-dependencies (in Phobos and at large)

Jonathan M Davis jmdavisProg at gmx.com
Thu Apr 25 20:23:19 PDT 2013


On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
> What we need is to re-arrange the module hierarchy (and we need that
> anyway) so that we split off the "concept" part of modules to a separate
> package.

> Thoughts? Other ideas?

I'm a bit divided on the idea. On the one hand, it allows us to reduce 
interdependencies. On the other hand, it's definitely complicating the module 
hierarchy. This whole idea is a bit like the .h/.cpp or .di/.d separation. On 
the whole, I prefer the model of shoving it all in one file, but given that 
Phobos is the standard library (of a _systems_ language no less), the added 
complication may very well be worth the benefits in dependency reduction.

Still, given that we're talking about templates here, most of it shouldn't end 
up in the generated executable or library if it's not used, and we've already 
been moving away from static constructors in Phobos, and global/module level 
variables should already be quite rare. And once Phobos is a shared library, 
the few global/module level variables we have should cost even less. So, I'm 
not sure that the extra complication is really worth it. If the compiler and 
linker are doing their job, the only real difference should be in how much the 
various modules in Phobos need to be parsed, which is very fast with dmd, and 
most programs of any size are going to pull in all of the dependencies anyway.

I'm inclined to avoid doing this if we don't really need to, but if there's a 
solid benefit to it, then it may be that we really should do something like 
this.

On a side note, given that we sometimes call eponymous templates like 
isForwardRange traits, calling the sub-module trait or traits rather than 
concepts might be better (probably std.trait given that std.traits is already 
taken, though that would probably then become std.trait.traits given that it's 
entirely made up of traits).

- Jonathan M Davis


More information about the Digitalmars-d mailing list