taking a character out of a string

bearophile bearophileHUGS at lycos.com
Mon Aug 18 19:58:14 PDT 2008


Michael P.:
> Any reason why you put:
> import std.stdio: putr = writefln;
> import std.string: removechars;
> 
> instead of just:
> import std.stdio;
> import std.string;

The putr/put is just a personal thing of mine, I prefer those names for the printing functions because they are shorter and simpler/faster to write, and equally clean. Those names in my D libs refer to real printing functions (instead of being just aliases) that have many improvements over the writefln/writef (Tango defines yet other printing functions, different from the Phobos ones).


The specification of the names you want to import from the modules is a good practice that allows you to:
- keep your namespace more clean, avoiding some name clashes, because import foo imports all the names in foo and some more (see below).
- show the person that reads the code (and isn't using an IDE) where each imported name used in the module comes from.

Note that the design of the D module system has some holes/rough edges still, for example the following program doesn't give a compilation error:

import std.stdio;
void main() {
    writefln(10);
    std.stdio.writefln(10);
    std.stdio.writef(10, \n);
}

It means the import imports the names inside the std.stdio module and the name std.stdio itself too (this has some practical consequences, for example you generally can't put inside a module named 'foo' a function named 'foo', because it may cause problems).
Hopefully similar silly problems in the D module system will be eventually seen as actual bugs, and fixed.

A better semantic is to change the module system to make this:
import somemodule;
mean just import the 'somemodule' module name in the current namespace.
So then somemodule.somefun() is legal but somefun() is not.
If you want (discouraged practice) to import all names from a module a specific syntax may be invented, like:
import somemodule.*;
Or something similar. After that somefun() can be used but somemodule.somefun() doesn't exists because the 'somemodule' name itself isn't imported in the current namespace.
There are various other problems in the module system (try using various modules for a little of time and you will probably be able to find various other silly situations  where it breaks apart) that can be solved sitting at a table and inventing (or just copying it from a language that has invented it before) a simple logically coherent system instead of the half-unfinished pile of things half-fixed and half copied from the Python module system, etc currently present in D 1.x.
I just hope that the current module system isn't fixed in stone, and such problems will be sorted out in D 2.x or even 3.x :-)

Bye,
bearophile


More information about the Digitalmars-d-learn mailing list