Early review of std.logger

Dicebot public at dicebot.lv
Wed Nov 6 05:21:15 PST 2013


On Tuesday, 5 November 2013 at 08:38:34 UTC, Robert Schadek wrote:
> Can you give an example, I'm not sure if I know what you mean.

Currently common approach is just adding top-level module imports 
like this:

```
module app;
import std.algorithm;
```

It has several issues:

1) Name clash if two modules define same symbol
2) Difficulties with tracking unused imports
3) Compilation speed penalty because of eager import in case it 
is only used in uninstantiated code branch.

However, D has 3 totally awesome import features that help to 
address all of this issues:

1) aliasing imports
```
import algo = std.algorithm;
```

It creates the very same namespace one is trying to achieve with 
namespace struct but without extra unused symbols and with full 
user control. Benefits both readability of application (obvious 
where namespace comes from) and readability of imported module 
(less redundant nesting)

2) importing specific symbols
```
import std.algorithm : remove;
```

Often module is used only for one or two functions. Mentioning 
those explicitly will avoid accidental clashes with irrelevant 
module symbols and acts as a nice self-documentation tool.

3) scope-local imports
```
template tmpl(T)
{
     import std.algorithm : remove;
}
```

scope local imports are just awesome. Paired with explicit symbol 
mentioning they almost completely eliminate risk of symbol 
clashes and make it easy to remove unused imports as you change 
the code. Also they don't happen unless scope is actually 
instantiated and thus can save some compilation times.

If all these nice tools D provides are used, any concern about 
symbol naming becomes irrelevant and having module-scope global 
names with no extra qualification becomes most KISS thing to do.


More information about the Digitalmars-d mailing list