phobos dependencies

[H. S. Teoh]

On Fri, Dec 20, 2013 at 10:06:01AM +0100, 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.

But we're only doing this for Phobos. You can still use global imports
in your own modules. I think for Phobos this makes sense, because it's
the standard *library*, which means all of its pieces will always be
available (being, y'know, standard), and you really only care about what
that particular piece of functionality you're using imports. When you
import std.algorithm.find, you don't really care about what
std.algorithm.cartesianProduct imports, do you?


> 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.

In your own code you can still use imports at the top of the file. We
never said we're going to get rid of that.


T

-- 
IBM = I Blame Microsoft