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)

#1 : Automatic self module FQN availability
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?


#2 : FQN names are always publicly imported
-----    -----
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?
}


#3 : Chained FQNs
-----    -----
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)
}

#4: Selective import and alias import bring names to the primary 
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:

 #1 : Automatic self module FQN availability
 A module declaration makes the module fully qualified name available?

That's interesting. Don't know anything about it though.
 #2 : FQN names are always publicly imported

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

 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.
 #4: Selective import and alias import bring names to the primary 
 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:
 
 #1 : Automatic self module FQN availability
 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.
 #2 : FQN names are always publicly imported

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

Hum, easily fixable I guess (in the IDE).
 #4: Selective import and alias import bring names to the primary 
 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.
 #3 : Chained FQNs

 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