Import improvement

[Andrei Alexandrescu]

On 10/15/12 8:43 AM, Manu wrote:
> So I'm getting sick of this in my files:
[snip litany of imports]
> This is obviously silly.

Agreed.

> I know this could be improved with some care, more liberal public
> imports (dangerous, you risk ending up with EVERYTHING as public import
> if it sticks as a standard convention), better maintained
> dependencies... but it's not realistic in a production environment. That
> sort of maintenance just never happens.
>
> I suggest expanding the selective import mechanism to extend to modules,
> not just functions within a module, eg:
>
> module stache.states.ingamestate;
>
> import fuji: filesystem, render, matrix, material, primitive, system, font;
> import std: xml, string, conv, random, algorithm;
> import stache: game, battlecamera;
> import stache.i: statemachine, entity, collider;
> import stache.entity: combatant, paimei;
> import stache.thinkers: localplayer, nullthinker;
> import stache.sound: soundset, music;
> import stache.util.eventtypes;
>
> This is much better! Saved ~25 lines of import rubbish, and it also
> enforces logical grouping; individual import statements tends to lead to
> related submodules being distanced from eachother, this way, they appear
> on the same line.
>
> Surely this has been considered before. Any reasons it's not supported?

I don't think imports from a specific package have been considered.

In my personal opinion, imports are a necessary evil and it's sort of a 
bummer that the most accessible place in any source file - the top lines 
- is occupied by the crappy legal disclaimer (which, after having talked 
to a lawyer, I always put at the bottom since being at the top is not a 
requirement), and the litany of imports that the module is using. I'd 
make all imports local or put them at the bottom of the file if it 
weren't too much of a shock to others.

Three remarks on this particular problem.

1. I expect large packages to introduce a module "all.di" or "_.di" to 
publicly import everything in the package. That could help some use cases.

2. The import declaration accepts a list of modules, and several may be 
on one line. I think that's a significant positive difference from C, 
C++, or Go, all of which force one imported module per line. I always 
advocate imports from the same package in the same "import" declaration, 
ordered alphabetically:

import fuji.filesystem, fuji.font, fuji.material, fuji.matrix,
     fuji.primitive, fuji.render, fuji.system;
import std.algorithm, std.conv, std.random, std.string, std.xml;
...

That makes the existing system much more palatable.

3. I think local imports are currently underutilized. It would be 
interesting to see what kind of project dynamics they enable.


Andrei