www.digitalmars.com         C & C++   DMDScript  

D - The way import works

reply "Nicolas Repiquet" <deadcow-remove-this free.fr> writes:
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
Nov 03 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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




 it, and deleting "import b" in 'a' dont lead to an error in main !

 Am i understandable ? Sorry if not.

 -- Nicolas Repiquet
Nov 03 2003
parent reply "Nicolas Repiquet" <deadcow-remove-this free.fr> writes:
"Charles Sanders" <sanders-consulting comcast.net> a écrit dans le message
news: bo67jl$1rhu$1 digitaldaemon.com...


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



Excuse me, english is not my mother language thus it's sometime hard to
transcibe intentions in words. I am really sorry if I offended anyone.
Please replace "should"s by "may"s or anything implying modesty because I
dont wanna claim anything, just suggest.

Regards.

-- Nicolas Repiquet
Nov 03 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
It didn't worry me; this is a robust bunch of people. :)

Having said that, I guess Charles' advice is useful in a general way. There
are a lot less friendly newsgroups

"Nicolas Repiquet" <deadcow-remove-this free.fr> wrote in message
news:bo6s0q$2ou4$1 digitaldaemon.com...

 "Charles Sanders" <sanders-consulting comcast.net> a écrit dans le message
 news: bo67jl$1rhu$1 digitaldaemon.com...


 Try to stay away from "shoulds" "this is the way it should be done"







 it comes accross badly.



 Excuse me, english is not my mother language thus it's sometime hard to
 transcibe intentions in words. I am really sorry if I offended anyone.
 Please replace "should"s by "may"s or anything implying modesty because I
 dont wanna claim anything, just suggest.

 Regards.

 -- Nicolas Repiquet
Nov 03 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Yea sorry I was in a bad mood that morning :/.

C

"Nicolas Repiquet" <deadcow-remove-this free.fr> wrote in message
news:bo6s0q$2ou4$1 digitaldaemon.com...

 "Charles Sanders" <sanders-consulting comcast.net> a écrit dans le message
 news: bo67jl$1rhu$1 digitaldaemon.com...


 Try to stay away from "shoulds" "this is the way it should be done"







 it comes accross badly.



 Excuse me, english is not my mother language thus it's sometime hard to
 transcibe intentions in words. I am really sorry if I offended anyone.
 Please replace "should"s by "may"s or anything implying modesty because I
 dont wanna claim anything, just suggest.

 Regards.

 -- Nicolas Repiquet
Nov 05 2003
parent Felix <Felix_member pathlink.com> writes:
Nicolas answer also stands for me...
(I am in the same situation, even worse...)
So, sorry for offences...


In article <boa41n$1a56$1 digitaldaemon.com>, Charles Sanders says...

Yea sorry I was in a bad mood that morning :/.

C

"Nicolas Repiquet" <deadcow-remove-this free.fr> wrote in message
news:bo6s0q$2ou4$1 digitaldaemon.com...

 "Charles Sanders" <sanders-consulting comcast.net> a écrit dans le message
 news: bo67jl$1rhu$1 digitaldaemon.com...


 Try to stay away from "shoulds" "this is the way it should be done"







 it comes accross badly.



 Excuse me, english is not my mother language thus it's sometime hard to
 transcibe intentions in words. I am really sorry if I offended anyone.
 Please replace "should"s by "may"s or anything implying modesty because I
 dont wanna claim anything, just suggest.

 Regards.

 -- Nicolas Repiquet
Nov 05 2003
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Nov 03 2003
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
Nov 03 2003
prev sibling next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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







 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




 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
Nov 03 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Nov 03 2003
prev sibling next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
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.
Nov 03 2003
prev sibling next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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







 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




 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
Nov 03 2003
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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



to have both explicit private and public.

-Anderson
Nov 03 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 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



 to have both explicit private and public.



Even better! Let's do that. Most implicit things are a specious convenience
... apart from implicit template instantiation, of course <G>
Nov 03 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:


to have both explicit private and public.



For now we could add this to a list of suggested design/coding best practices
methods for D.

Is there such a thing now? The WIKI site?

p.s.
DON'T put curly brace placement and other such stuff in the design/coding best
practices. 



 Nov 05 2003



  parent  J C Calvarese <jcc7 cox.net>  writes:


Mark T wrote:


(With no particular preference in mind) Of course another way would be 
to have both explicit private and public.



 
 For now we could add this to a list of suggested design/coding best practices
 methods for D.
 
 Is there such a thing now? The WIKI site?
 
 p.s.
 DON'T put curly brace placement and other such stuff in the design/coding best
 practices. 
 
 



page is stymieing)...

http://www.wikiservice.at/d/wiki.cgi?BestPractices

Anyone can edit it, so edit away.


Justin



 Nov 06 2003



prev sibling next sibling parent  J C Calvarese <jcc7 cox.net>  writes:


Hauke Duden wrote:

 Nicolas Repiquet wrote:
 

 D's import taste too much like #include :







 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 is my preference as well.  It doesn't seem particularly "safe" to 
use the powerful public import (I ran into a lot of problems with 
conflicting imports before "private import" was available), so it'd help 
to emphasize the danger by requiring an explicit "public import".  I 
think the default syntax should be less tricky for the novice programmer.

Justin


 
 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
 






 Nov 03 2003



prev sibling  parent  "Sarat Venugopal" <sarat banspam.huelix.com>  writes:


In fact, I favor the Python way here.

Case 1:
    import foo
    foo.bar()     # Explicitly qualify the module here

Case 2:
    from foo import bar # Only interested in bar()
    bar()    #No qualification needed

Case 3:
    from foo import * # Pull everything in foo into current scope
    bar()
    spam()

I don't know whether there are efficiency gains to be derived from limiting
the amount of stuff actually imported from
a module. In Case 1, it is a little more typing - but the advantages far
outweigh the small inconvenience.

import mod1
import mod2

mod1.foo()
mod2.foo() # No name conflicts here

I guess this is easier for the compiler as well as the programmer. This
approach minimizes name collisions, should improve compile times, and
generally improve robustness.

This is not meant to be yet another
"implement-my-favorite-language-feature-in-d" suggestion. Just something I
thought was worth emulating and found nearly foolproof.

Cheers,
Sarat



"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







 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




 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




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003



 Nov 04 2003



prev sibling  parent  Juan C. <Juan_member pathlink.com>  writes:


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






 Nov 03 2003