On 12/20/13 1:06 AM, Meta wrote:
On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei Alexandrescu wrote:
2. Push imports from top level into the entities (functions, classes
etc) that use them.
2 comes with its own problems, though. With imports at the top, you can
easily tell what the module imports at a glance. Putting imports into
the deepest possible scopes where they are used will make it a huge
chore to hunt all the imports down. You can of course grep for "import"
(or ctrl+f for more plebeian editors), but you still don't have that
singular list in one place that you can easily look at to tell what the
module imports.
I think that's a price we need to pay the same way cars replaced
carriages in spite of them having a lot of disadvantages at the time.
It's simply a mindset to do away with.
Transitive imports can be figured with:
dmd -c -o- -v module | grep '^import '
I felt the need for non-transitive imports, and I'm sure a tool will
show up before long.
Local imports are the future. Better get used to them.
Also, as was mentioned before, some imports (or lack of) will go
unnoticed until the particular template or template path that it resides
in gets instantiated. I don't relish the idea of thinking that my code
is all clear, then getting some missing dependency error down the line
after refactoring. This will make code more brittle.
Unittests/coverage to the rescue. Tooling tooling tooling.
Andrei
