taking a character out of a string

[Michael P.]

bearophile Wrote:

> 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


Okay, I get it. Thanks. And I got the space removing thing working too.
-Michael P.