Le 09/11/2011 14:15, Trass3r a écrit :
>> 2. what is your opinion about public import ? In C++, "hidden" or
>> "implicit" #includes is a common source of compilation problems (order
>> of #includes), I tend to think it's a bad thing.
>
> It can be quite useful. I use it often for C library wrappers. As soon
> as you import the wrapper code you automatically import the bindings to
> be able to use constants etc.

I agree it's useful in this special case, but in the general case, I think it encourages sloppy programming: it binds modules together more than necessary, and it seems that once public import is used, it can be very hard to remove it afterward.

Le 09/11/2011 14:50, Jacob Carlborg a écrit :

>> 2. what is your opinion about public import ? In C++, "hidden" or
>> "implicit" #includes is a common source of compilation problems (order
>> of #includes), I tend to think it's a bad thing.
>
> Sometimes public imports are useful. It's possible to emulate Java's
> import foo.* using public imports:
>
> // a._.d
>
> public import a.foo;
> public import a.bar;
>
> // foobar.d
> import a._;
>
> It can also be useful to have public imports if you have a module with
> array functions and a module with string functions. Then the string
> module can publicly import the array module since all(most) array
> functions will work with strings as well.
>

As I said, this is considered sloppy programming, and both in Java and in Python ("from xxx import *"), this practice is highly discouraged. This is because you bind modules together more than necessary.
If you need in module A name B.b and deprecate B.b later, then there is no reason to have imported everything from B.
In Java, the IDE does the work of importing the exact packages/classes needed for you, but in Python, you have to do it by hand. It seems that it would be just as bad in D as in Python since compilation errors don't appear until templates are instantiated.

Dude