Walter: Import clarifications.

Bruno Medeiros brunodomedeiros+spam at com.gmail
Tue Jul 24 17:07:35 PDT 2007


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



More information about the Digitalmars-d mailing list