D's import taste too much like #include :

<file a.d>

module a;

import b;

doSomethingA() {}

<file b.d>

module b;

doSomethingB() {}

<file main.d>

import a;

void main() {
    doSomethingA();
    doSomethingB();
}



Sad but true : the code above works perfectly =)

"import" should be interpreted as "use" : importing 'a' dont automagicaly import 'b'. It's the java way for import. So main.d must be rewrote as :

import a;
import b;

...

It's clearer as used modules are explicitly imported in each module that use it, and deleting "import b" in 'a' dont lead to an error in main !

Am i understandable ? Sorry if not.

-- Nicolas Repiquet

Try to stay away from "shoulds" "this is the way it should be done" please it comes accross badly.

Use

private import my_module;

C

"Nicolas Repiquet" <deadcow-remove-this@free.fr> wrote in message news:bo66mr$1q6a$1@digitaldaemon.com...
> D's import taste too much like #include :
>
> <file a.d>
>
> module a;
>
> import b;
>
> doSomethingA() {}
>
> <file b.d>
>
> module b;
>
> doSomethingB() {}
>
> <file main.d>
>
> import a;
>
> void main() {
>     doSomethingA();
>     doSomethingB();
> }
>
>
>
> Sad but true : the code above works perfectly =)
>
> "import" should be interpreted as "use" : importing 'a' dont automagicaly import 'b'. It's the java way for import. So main.d must be rewrote as :
>
> import a;
> import b;
>
> ...
>
> It's clearer as used modules are explicitly imported in each module that
use
> it, and deleting "import b" in 'a' dont lead to an error in main !
>
> Am i understandable ? Sorry if not.
>
> -- Nicolas Repiquet
>
>
>
>

Nicolas Repiquet wrote:
> D's import taste too much like #include :
> <file a.d>
> 
> module a;
> 
> import b;
> 
> doSomethingA() {}
> 
> <file b.d>
> 
> module b;
> 
> doSomethingB() {}
> 
> <file main.d>
> 
> import a;
> 
> void main() {
>     doSomethingA();
>     doSomethingB();
> }
> 
> Sad but true : the code above works perfectly =)
> 
> "import" should be interpreted as "use" : importing 'a' dont automagicaly
> import 'b'. It's the java way for import. So main.d must be rewrote as :

I agree completely!

I was going to write a post on this topic just when I read yours ;).

D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.

BUT I think that this should be the default. The only real application I see for the current default public import is when you want to have some sort of collector module that can be used to import a whole bunch of other modules at once. But since one usually imports a module to use it in the current module, this should almost always be a private import. Otherwise the code can quickly become a dependency mess, where one module fails to compile when an import statement in another module is changed.

So IMHO "import" should mean "private import" and the other recursive import should be called "public import".

This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable default.

And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!

Hauke

Hauke Duden wrote:
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating.

May I add that this very scenario seems to have occurred in the development of phobos? ;)

Hauke

I disagree, I expect it to behave like public imports unless I explicitly tell it not too, like include statements.

C


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bo68eo$1sl7$1@digitaldaemon.com...
> Nicolas Repiquet wrote:
> > D's import taste too much like #include :
> > <file a.d>
> >
> > module a;
> >
> > import b;
> >
> > doSomethingA() {}
> >
> > <file b.d>
> >
> > module b;
> >
> > doSomethingB() {}
> >
> > <file main.d>
> >
> > import a;
> >
> > void main() {
> >     doSomethingA();
> >     doSomethingB();
> > }
> >
> > Sad but true : the code above works perfectly =)
> >
> > "import" should be interpreted as "use" : importing 'a' dont
automagicaly
> > import 'b'. It's the java way for import. So main.d must be rewrote as :
>
> I agree completely!
>
> I was going to write a post on this topic just when I read yours ;).
>
> D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.
>
> BUT I think that this should be the default. The only real application I see for the current default public import is when you want to have some sort of collector module that can be used to import a whole bunch of other modules at once. But since one usually imports a module to use it in the current module, this should almost always be a private import. Otherwise the code can quickly become a dependency mess, where one module fails to compile when an import statement in another module is changed.
>
> So IMHO "import" should mean "private import" and the other recursive import should be called "public import".
>
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable
default.
>
> And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
>
> Hauke
>

In article <bo68eo$1sl7$1@digitaldaemon.com>, Hauke Duden says...
>
>Nicolas Repiquet wrote:
>> D's import taste too much like #include :
>> <file a.d>
>> 
>> module a;
>> 
>> import b;
>> 
>> doSomethingA() {}
>> 
>> <file b.d>
>> 
>> module b;
>> 
>> doSomethingB() {}
>> 
>> <file main.d>
>> 
>> import a;
>> 
>> void main() {
>>     doSomethingA();
>>     doSomethingB();
>> }
>> 
>> Sad but true : the code above works perfectly =)
>> 
>> "import" should be interpreted as "use" : importing 'a' dont automagicaly import 'b'. It's the java way for import. So main.d must be rewrote as :
>
>I agree completely!
>
>I was going to write a post on this topic just when I read yours ;).
>
>D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.
>
>BUT I think that this should be the default.

I agree.  I suggested this myself a while back and was
shot down because it's inconsistant default class protection
mode being public by default.

I have not thought through all the ramifications, but I agree with you. I was bitten by this recently by importing things from Phobos itself.

Unless someone can offer a compelling counter argument, this seems like a good change to make.

Walter, your thoughts?


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bo68eo$1sl7$1@digitaldaemon.com...
> Nicolas Repiquet wrote:
> > D's import taste too much like #include :
> > <file a.d>
> >
> > module a;
> >
> > import b;
> >
> > doSomethingA() {}
> >
> > <file b.d>
> >
> > module b;
> >
> > doSomethingB() {}
> >
> > <file main.d>
> >
> > import a;
> >
> > void main() {
> >     doSomethingA();
> >     doSomethingB();
> > }
> >
> > Sad but true : the code above works perfectly =)
> >
> > "import" should be interpreted as "use" : importing 'a' dont
automagicaly
> > import 'b'. It's the java way for import. So main.d must be rewrote as :
>
> I agree completely!
>
> I was going to write a post on this topic just when I read yours ;).
>
> D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.
>
> BUT I think that this should be the default. The only real application I see for the current default public import is when you want to have some sort of collector module that can be used to import a whole bunch of other modules at once. But since one usually imports a module to use it in the current module, this should almost always be a private import. Otherwise the code can quickly become a dependency mess, where one module fails to compile when an import statement in another module is changed.
>
> So IMHO "import" should mean "private import" and the other recursive import should be called "public import".
>
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable
default.
>
> And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
>
> Hauke
>

That's my opinion as well.

The same system has worked in Delphi perfectly good.

-eye

Charles Sanders wrote:
> I disagree, I expect it to behave like public imports unless I explicitly
> tell it not too, like include statements.
> 
> C

Hauke Duden wrote:

> [Snip]


> So IMHO "import" should mean "private import" and the other recursive import should be called "public import".
>
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable default.
>
> And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
>
> Hauke
>
(With no particular preference in mind) Of course another way would be to have both explicit private and public.

-Anderson

I think this may be one of the few times I agree with Walter. Scary.

In article <bo66mr$1q6a$1@digitaldaemon.com>, Nicolas Repiquet says...
>
>D's import taste too much like #include :
>
><file a.d>
>
>module a;
>
>import b;
>
>doSomethingA() {}
>
><file b.d>
>
>module b;
>
>doSomethingB() {}
>
><file main.d>
>
>import a;
>
>void main() {
>    doSomethingA();
>    doSomethingB();
>}
>
>
>
>Sad but true : the code above works perfectly =)
>
>"import" should be interpreted as "use" : importing 'a' dont automagicaly import 'b'. It's the java way for import. So main.d must be rewrote as :
>
>import a;
>import b;
>
>...
>
>It's clearer as used modules are explicitly imported in each module that use it, and deleting "import b" in 'a' dont lead to an error in main !
>
>Am i understandable ? Sorry if not.
>
>-- Nicolas Repiquet
>
>
>
>