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


 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
 
 


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 Mäkelä <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


 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


 
 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;


 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 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;


 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 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;


 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 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