On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu
wrote:
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.
It is a common practice (usually all.di) but perhaps it could
help to establish an official convention. Nothing in the
language, just the styleguide. (I know this has already come up
and been discussed.)
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.
I've done this very thing for eons, and yes you are quite right!
(Although my formatting is different, but I digress.) That said,
I think the OP still has a valid, even quite strong point.
Consider, in comparison to your sample:
import fuji.( filesystem, font, material, matrix, primitive,
render, system );
import std.( algorithm, conv, random, string, xml );
Certainly less visual noise. An even *better* level of
improvement comes if we provide an alternate and similar syntax
for selective imports, so that they no longer have to be
separated.
import std.( algorithm, conv, random, xml,
stdio:( write, writef, writefln ),
string:( munch, splitLines, xformat, xsformat )
);
As for implementation, how difficult is it for the compiler to
internally expand something like this into the traditional litany?
3. I think local imports are currently underutilized. It would
be interesting to see what kind of project dynamics they enable.
I can agree with this.
-- Chris Nicholson-Sauls
