• Sergey Gromov <snake.scaly gmail.com> Feb 01 2008
• bearophile <bearophileHUGS lycos.com> Feb 01 2008
• Bill Baxter <dnewsgroup billbaxter.com> Feb 01 2008
• bearophile <bearophileHUGS lycos.com> Feb 01 2008

Sergey Gromov <snake.scaly gmail.com> writes:

bearophile Wrote:

 Sergey Gromov:
 import std.conv;
 import std.stdio;
 import std.format;
 import std.c.windows.windows;


 I think everyone has to start qualifying all the imports, so can you replace
all those with:
 
 import std.conv: name1, name2, ...;
 import std.stdio: name3, name4, ...;
 import std.format: name5, name6, ...;
 import std.c.windows.windows: name7, name8, ...;


It's a module, it works fine, why bother ?  Anyway, if I were to do
something about it, I'd prefer to static import them and use full
names in the code.  What you've proposed looks to me like
a real mess.

SnakE

bearophile <bearophileHUGS lycos.com> writes:

Sergey Gromov:
 It's a module, it works fine, why bother ?  Anyway, if I were to do
 something about it, I'd prefer to static import them and use full
 names in the code.  What you've proposed looks to me like
 a real mess.


It's way better than having all those names and many more other in the
namespace, plus not knowing where they come from. So I think you are wrong.

Bye,
bearophile

Bill Baxter <dnewsgroup billbaxter.com> writes:

bearophile wrote:
 Sergey Gromov:
 It's a module, it works fine, why bother ?  Anyway, if I were to do
 something about it, I'd prefer to static import them and use full
 names in the code.  What you've proposed looks to me like
 a real mess.


 It's way better than having all those names and many more other in the
namespace, plus not knowing where they come from. So I think you are wrong.
 
 Bye,
 bearophile


For modules you plan to use heavily, renamed import is the way to go if 
you want to keep your namespace tidy, but don't want to type crazy long 
FQN identifiers.

import IO = std.stdio;
import Fmt = std.format;

That plus judicious use of selectivly imported symbol like bearophile 
mentioned, makes keeping your namespaces clean not so painful.

I think python's a little different though in that there is no real 
"private".  A language with a public-everything philosophy really needs 
to watch out for namespace pollution.

--bb

bearophile <bearophileHUGS lycos.com> writes:

Bill Baxter:
 I think python's a little different though in that there is no real 
 "private".  A language with a public-everything philosophy really needs 
 to watch out for namespace pollution.


I agree, I wasn't comparing the two languages because the situations are a
little different (and in D you have function signatures that are enforced more
by the compiler, that changes the situation a lot).
But in Python you can use names starting with _ and the __all__ to improve the
situation some:

The public names defined by a module are determined by checking the module's
namespace for a variable named __all__; if defined, it must be a sequence of
strings which are names defined or imported by that module. The names given in
__all__ are all considered public and are required to exist. If __all__ is not
defined, the set of public names includes all names found in the module's
namespace which do not begin with an underscore character (‘_’). __all__ should
contain the entire public API. It is intended to avoid accidentally exporting
items that are not part of the API (such as library modules which were imported
and used within the module).<


(You can also see my recent post about the module topic).

Bye,
bearophile