www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - what's the difference between 'static import =' and 'import ='?

reply "Boris Wang" <nano.kago hotmail.com> writes:
For example:

    * static import io = std.stdio;
    * import io = std.stdio;

We must use io prefix to access std.stdio, in above two situation. 
Jul 18 2006
parent reply John Reimer <John_member pathlink.com> writes:
In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
For example:

    * static import io = std.stdio;
    * import io = std.stdio;

Good question. Have you tested these first to see what happens or if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :) -JJR
Jul 18 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
For example:

    * static import io = std.stdio;
    * import io = std.stdio;

Good question. Have you tested these first to see what happens or if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

There is no difference. They function in an identical manner. static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 19/07/2006 4:22:03 PM
Jul 18 2006
parent reply John Reimer <John_member pathlink.com> writes:
In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek Parnell says...
On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
For example:

    * static import io = std.stdio;
    * import io = std.stdio;

Good question. Have you tested these first to see what happens or if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

There is no difference. They function in an identical manner. static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

Ah... ok. Good to know. I guess we have a very flexible system in place, capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR
Jul 19 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"John Reimer" <John_member pathlink.com>
дϢ:e9knp5$fk1$1 digitaldaemon.com...
 In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek Parnell 
 says...
On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
For example:

    * static import io = std.stdio;
    * import io = std.stdio;

Good question. Have you tested these first to see what happens or if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

There is no difference. They function in an identical manner. static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

Ah... ok. Good to know. I guess we have a very flexible system in place, capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }
Jul 19 2006
next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e9kp1b$hcm$1 digitaldaemon.com>, Boris Wang says...
 Ah... ok. Good to know. I guess we have a very flexible system in place, 
 capable
 of accomodating several styles.  And Walter gets to have his "static 
 import" as
 well. :)

 -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

Yes, I understand that there's a bit of a redundancy in the current implementation, but I'm not sure the above solution is good one or really necessary. An import statement seems to give the compiler a quick lookup hint, and meanwhile acts as a documentation tool indicating which module is going to be used in a program. The above is certainly a possibility for what might be termed "implied importing". But I'm not quite comfortable with it. At this point, I don't have any comments to the negative other than that, for the time being, I think we have pushed the import issue far enough. :) -JJR
Jul 19 2006
parent reply Tyro <ridimz yahoo.com> writes:
John Reimer wrote:
 In article <e9kp1b$hcm$1 digitaldaemon.com>, Boris Wang says...
 Ah... ok. Good to know. I guess we have a very flexible system in place, 
 capable
 of accomodating several styles.  And Walter gets to have his "static 
 import" as
 well. :)

 -JJR

Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

Yes, I understand that there's a bit of a redundancy in the current implementation, but I'm not sure the above solution is good one or really necessary. An import statement seems to give the compiler a quick lookup hint, and meanwhile acts as a documentation tool indicating which module is going to be used in a program. The above is certainly a possibility for what might be termed "implied importing". But I'm not quite comfortable with it. At this point, I don't have any comments to the negative other than that, for the time being, I think we have pushed the import issue far enough. :) -JJR

List time I checked this was not implemented in D. For that matter it has never been implemented in D. If you want to reference a function in a module you have to import the module or, in the case of the most recent implementation, selectively import from the module in order to access the desired functionality. As I understand it, the question Boris is asking is why do this: | import std.string; | void main() | { | writefln("Now I can use it"); | } When you can do this: | //import nothing | void main() | { | std.string.writefln("Here I simply use it"); | } I think he's got a point. The compiler already knows how to find std.string and it can decipher whether or not a requested functionality is implemented in the module. Therefore it should be smart enough to *implicitly* import that function/module using FQNs alone. Andrew C. Edwards
Jul 19 2006
next sibling parent Jari-Matti Mkel <Jari-Matti_member pathlink.com> writes:
In article <e9l4se$1789$1 digitaldaemon.com>, Tyro says...

The compiler already knows how to find std.string and it can decipher 
whether or not a requested functionality is implemented in the module. 
Therefore it should be smart enough to *implicitly* import that 
function/module using FQNs alone.

Yes, I believe we all understand this. But as JJR already said it quite well, I think the import issues are solved for now. An explicit import statement is more self documenting and it's helping tools like Build and IDE's with the name lookup. -- Jari-Matti
Jul 19 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Tyro wrote:
 John Reimer wrote:
 In article <e9kp1b$hcm$1 digitaldaemon.com>, Boris Wang says...
 Ah... ok. Good to know. I guess we have a very flexible system in 
 place, capable
 of accomodating several styles.  And Walter gets to have his "static 
 import" as
 well. :)

 -JJR

Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

Yes, I understand that there's a bit of a redundancy in the current implementation, but I'm not sure the above solution is good one or really necessary. An import statement seems to give the compiler a quick lookup hint, and meanwhile acts as a documentation tool indicating which module is going to be used in a program. The above is certainly a possibility for what might be termed "implied importing". But I'm not quite comfortable with it. At this point, I don't have any comments to the negative other than that, for the time being, I think we have pushed the import issue far enough. :) -JJR

List time I checked this was not implemented in D. For that matter it has never been implemented in D. If you want to reference a function in a module you have to import the module or, in the case of the most recent implementation, selectively import from the module in order to access the desired functionality. As I understand it, the question Boris is asking is why do this: | import std.string; | void main() | { | writefln("Now I can use it"); | } When you can do this: | //import nothing | void main() | { | std.string.writefln("Here I simply use it"); | } I think he's got a point. The compiler already knows how to find std.string and it can decipher whether or not a requested functionality is implemented in the module. Therefore it should be smart enough to *implicitly* import that function/module using FQNs alone. Andrew C. Edwards

But how does it know that std.string is a module? It could be a sequence of classes, for example. class std { class string { void writefln(str[]...); } } If you're not using anything from std, I think that would be perfectly legal. Unlikely in the case of std.string, but in general... Declaring imports is IMHO a lot like declaring variables. Not strictly necessary, but it saves you from lots of hard-to-track down bugs.
Jul 19 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e9kp1b$hcm$1 digitaldaemon.com>, Boris Wang says...
Why not discard the sentence 'static import' ? When you need FQN to access a 
package, just do it.

For example

int main(void)
{
    std.stdio.writefln("Just do it"); // not need any importing
    ...
}

This won't work because its not guaranteed to be non-ambiguous. Thanks to how D layous out namespaces, the FQN "std.stdio.writefln" isn't necessarily the method "writefln" in module "std.stdio". For example, the following module: // std.d module std; struct stdio{ class writefln{ static opCall(){ /*...*/ } } } .. could be placed on DMD's include path and match the 'implicit' import you describe above. This more or less requires a series of compiler behaviors, none of which are a really good idea IMO. Should the compiler accept all possible variants of an FQN for matching, then you get this in the worst case for *every* FQN: - Parse *all* files on the current include path for matching FQN's - Report an ambiguious match as either an error or warning - In the case of a warning, pick one of the matching modules for inclusion and continue. - EricAnderton at yahoo
Jul 19 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
pragma wrote:
 In article <e9kp1b$hcm$1 digitaldaemon.com>, Boris Wang says...
 Why not discard the sentence 'static import' ? When you need FQN to access a 
 package, just do it.

 For example

 int main(void)
 {
    std.stdio.writefln("Just do it"); // not need any importing
    ...
 }

This won't work because its not guaranteed to be non-ambiguous. Thanks to how D layous out namespaces, the FQN "std.stdio.writefln" isn't necessarily the method "writefln" in module "std.stdio". For example, the following module: // std.d module std; struct stdio{ class writefln{ static opCall(){ /*...*/ } } } ... could be placed on DMD's include path and match the 'implicit' import you describe above. This more or less requires a series of compiler behaviors, none of which are a really good idea IMO. Should the compiler accept all possible variants of an FQN for matching, then you get this in the worst case for *every* FQN: - Parse *all* files on the current include path for matching FQN's - Report an ambiguious match as either an error or warning - In the case of a warning, pick one of the matching modules for inclusion and continue. - EricAnderton at yahoo

Forget the option of reporting an warning. Such situation should be an error, just as this is: import pack; import pack.foo; // pack conflicts. And the the compiler search behavior would be complicated. For an access like: x.y.z.foo(); Then for each path in the include path, search the root dir for a x module or package. If there is more than one match (or no matches) report an error. Otherwise, use the found match, and recurse the search. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 20 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Boris Wang wrote:
 "John Reimer" <John_member pathlink.com>
дϢ:e9knp5$fk1$1 digitaldaemon.com...
 
In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek Parnell 
says...

On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:


In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...

For example:

   * static import io = std.stdio;
   * import io = std.stdio;

Good question. Have you tested these first to see what happens or if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

There is no difference. They function in an identical manner. static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

Ah... ok. Good to know. I guess we have a very flexible system in place, capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

I could only be comfortable with this if it only worked with the standard library (things in the std package). And even then, it might require that people can't name things 'std'. Nah, I prefer explicit imports. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 19 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Boris Wang wrote:
 "John Reimer" <John_member pathlink.com>
дϢ:e9knp5$fk1$1 digitaldaemon.com...
 In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek Parnell 
 says...
 On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
 For example:

    * static import io = std.stdio;
    * import io = std.stdio;

the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above). Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 20 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 Boris Wang wrote:
 "John Reimer" <John_member pathlink.com> 
 дϢ:e9knp5$fk1$1 digitaldaemon.com...
 In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek 
 Parnell says...
 On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
 For example:

    * static import io = std.stdio;
    * import io = std.stdio;

if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

place, capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above). Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages.

Well, you can do this already with a ---- module usingphobos; public import stdio = std.stdio; public import string = std.string; (etc) ---- import usingphobos; void main() { stdio.writefln("Yes it works!"); } ---- All it takes is a single import at the top of each file.
Jul 20 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Don Clugston wrote:
 Bruno Medeiros wrote:
 Boris Wang wrote:
 "John Reimer" <John_member pathlink.com> 
 дϢ:e9knp5$fk1$1 digitaldaemon.com...
 In article <9vh8joe3sla0.1se36qil8397i$.dlg 40tude.net>, Derek 
 Parnell says...
 On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

 In article <e9k8bv$2usv$1 digitaldaemon.com>, Boris Wang says...
 For example:

    * static import io = std.stdio;
    * import io = std.stdio;

if the first even works? I think that might answer your question. Then you can tell those of us who haven't had a chance to try yet. :)

static import XXX; import XXX = whatever; static import XXX = whatever; all require that 'XXX' be used to reference members in the code. However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

place, capable of accomodating several styles. And Walter gets to have his "static import" as well. :) -JJR

No, I don't think so. Something need refining. Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it. For example int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }

I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above). Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages.

Well, you can do this already with a ---- module usingphobos; public import stdio = std.stdio; public import string = std.string; (etc) ---- import usingphobos; void main() { stdio.writefln("Yes it works!"); } ---- All it takes is a single import at the top of each file.

I know, that's what I call the fqnall trick. :) (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 20 2006