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