Suggestion - use local imports in Phobos

Tyler Jameson Little beatgammit at gmail.com
Thu Jun 6 19:12:28 PDT 2013


>>> 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.
>
> That's like saying that defining a local `i` variable for using 
> in a `for` loop breaks DRY, because you could have defined it 
> once at global scope.
>
> Importing the same module over and over does not break DRY, 
> just like calling the same function in multiple places does not 
> break DRY. Breaking DRY means to write the internal code of 
> that function in several places - or implementing the same 
> things in several modules.

I completely agree. I write a lot of Go code, and in Go, unused
imports are a compile-time error, which is a pretty nice feature
because you know what the dependencies are for a package. In D,
this is not the case (though I would like it to be a warning at
least, but that's another issue...), but at least Phobos can
declare which imports are needed, and where they are needed.

For example, if a unittest requires std.datetime, an import is
added to the top of the file. Then later, if this requirement is
removed, the import remains because it is not immediately obvious
if some other unittest needs it. Sooner or later, the imports
stack up and it's hard to tell which imports are required.

If unittest dependencies are localized, they can be removed from
the tests that do not need it. I think this would simplify the
task of removing inter-dependencies later if this ever becomes a
priority. This is already what I do in my own D code, and for
this very reason.

Just my 2c.


More information about the Digitalmars-d mailing list