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