On Tue, Jun 04, 2013 at 08:59:15PM +0200, Idan Arye wrote: [...] > Many modules import other modules solely for usage in unit tests. > Those imports are redundant if you don't unit-test Phobos - and most > projects written in D don't run the standard library unit tests. If > those imports were local to the unit test, they wouldn't be imported > in outside code.
AFAIK, Phobos code wraps such imports in version(unittest) blocks, so this shouldn't be a problem. If there are stray imports that aren't wrapped and are only needed for unittests, you should file a bug. [...] > Due to these characteristics of Phobos, I believe making the imports > local to the unit tests and templates that use them will reduce the > number of imports the compiler has to do. This breaks DRY because some imports are used by multiple unittests. As long as the imports are wrapped in version(unittest) blocks, I don't see this as a problem. > Another advantage of making the imports local(whenever possible) is > that it would make it easier to remove imports. Currently, if a change > to an implementation in Phobos removes it dependency on a module, you > can't remove them module's name from the import list, because maybe > some other part of this module needs that import. If that import was > local to the implementation that used it, you could remove the import > safely, knowing that if it is needed somewhere else, it is imported > locally there. This is a good point, not just for Phobos, but for D code in general. [...] > Also, I'm not really familiar with the internals of dmd - how much > impact will importing the same module many times have on the > compilation performance? Will it be more or less than what we save > by reducing the number of imported modules? [...] I may be wrong, but I seem to recall hearing/seeing somewhere that a repeated import is just ignored by DMD, since it has already loaded the imported module. If not, then DMD should be fixed to do that. :) T -- Doubt is a self-fulfilling prophecy.
