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