www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter: Import clarifications.

reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
As part of the effort to develop an Eclipse D IDE, I've been planning to 
create some amount of D-semantic-aware IDE functionality. Right now I've 
been working on an Open Definition like feature, and I've come across 
some issues I would like to have clarified, namely in regards to D 
import behavior.
The issues are as follow, and I've tested the following cases with the 
current DMD implementation, but I've just wanted to check if their 
behavior is indeed the intended behavior, since I don't think any of 
them are clearly defined in the D spec.
(these might also be some good points to clear up in the spec)


A module declaration makes the module fully qualified name available?
-----    -----
module pack.mod;

alias pack.mod mymod;
// OK because FQN "pack.mod" is automatically available?

alias mod mymod2;
// Fails because "mod" not available, correct?
-----    -----
The following is allowed however:
-----    -----
module writefln; // Notice the module name
import std.stdio;

void func() {
	writefln("SSS");
}
-----    -----
suggesting that the module name has less priority that the names in the 
module scope, even those from imports (ie, the secondary/background 
namespace). Correct?



-----    -----
module pack2.fooprivate;

int fooprivateImportVar;

-----    -----
module pack.sample;

import pack2.fooprivate; //Here we privately import the previous module

-----    -----
module test;
import pack.sample;

void func() {
   // And so fooprivateImportVar is not accessible
   //fooprivateImportVar++;

   // However the FQN names from the private import are accessible:
   alias pack2.fooprivate myfooprivate; // ok
   pack2.fooprivate.fooprivateImportVar++; // ok
   // Correct?
}



-----    -----
module pack2.foopublic;

int foopublicImportVar;

-----    -----
module pack.sample;

public import pack2.foopublic; // Here we have a public import

-----    -----
module test;
import pack.sample;

void func() {
   pack.sample.pack2.foopublic.foopublicImportVar++;
   // One can access an FQ name, chained from another one?? Correct?
   // (This one is damn ugly IMO)
}


namespace, and not the secondary namespace?
That is, if you have this:
   import mystdio = std.stdio;
   import std.stdio : writefln;
Then both 'mystdio' and 'writefln' will be first-class names in the 
scope (and will immediately conflict with other existing names), unlike 
the names imported by normal "content" imports, which go into the 
secondary/background namespace, and only conflict if referenced, correct?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 23 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruno Medeiros wrote:



 A module declaration makes the module fully qualified name available?


That's interesting.  Don't know anything about it though.





Sounds like bug 313.
http://d.puremagic.com/issues/show_bug.cgi?id=313







 void func() {
   pack.sample.pack2.foopublic.foopublicImportVar++;
   // One can access an FQ name, chained from another one?? Correct?
   // (This one is damn ugly IMO)
 }


I call that "consistent" rather than "damn ugly".  If [something] is a 
valid public symbol in module A, and we import A, then it should be 
possible to say A.[something], no matter what [something] is.



 namespace, and not the secondary namespace?
 That is, if you have this:
   import mystdio = std.stdio;
   import std.stdio : writefln;
 Then both 'mystdio' and 'writefln' will be first-class names in the 
 scope (and will immediately conflict with other existing names), unlike 
 the names imported by normal "content" imports, which go into the 
 secondary/background namespace, and only conflict if referenced, correct?


This one sounds like bug 314:
http://d.puremagic.com/issues/show_bug.cgi?id=314

--bb
Jul 23 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 Bruno Medeiros wrote:
 


 A module declaration makes the module fully qualified name available?


 
 That's interesting.  Don't know anything about it though.
 


I think it makes sense. It is as if the module declaration where like a 
class declaration:

   module pack.mod {
     imports...
     other names...
     etc...
   }

Where the 'pack.mod' symbol is available, but only if none other homonym 
is found first in the module scope.





 
 Sounds like bug 313.
 http://d.puremagic.com/issues/show_bug.cgi?id=313
 


Hum, easily fixable I guess (in the IDE).



 namespace, and not the secondary namespace?
 That is, if you have this:
   import mystdio = std.stdio;
   import std.stdio : writefln;
 Then both 'mystdio' and 'writefln' will be first-class names in the 
 scope (and will immediately conflict with other existing names), 
 unlike the names imported by normal "content" imports, which go into 
 the secondary/background namespace, and only conflict if referenced, 
 correct?


 
 This one sounds like bug 314:
 http://d.puremagic.com/issues/show_bug.cgi?id=314
 
 --bb


Hum... indeed for the selective import its kinda weird, but I think it 
made some sense for the aliasing imports. I could fix that, but I still 
would like some official confirmation.






 void func() {
   pack.sample.pack2.foopublic.foopublicImportVar++;
   // One can access an FQ name, chained from another one?? Correct?
   // (This one is damn ugly IMO)
 }


 I call that "consistent" rather than "damn ugly".  If [something] is a
 valid public symbol in module A, and we import A, then it should be
 possible to say A.[something], no matter what [something] is.


Well, I disagree. I think that A.[something] should only be valid when 
[something] is *defined* in A's scope. And you can't exactly call this 
rule inconsistent.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 24 2007