Walter: Import clarifications.

Bill Baxter dnewsgroup at billbaxter.com
Mon Jul 23 18:15:23 PDT 2007


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



More information about the Digitalmars-d mailing list