• Georg Wrede (63/63) Jul 12 2006 When I first saw "static import", I got the impression it's Walters Q&D,...

Georg Wrede <georg.wrede nospam.org> writes:

When I first saw "static import", I got the impression it's Walters Q&D, 
incomplete fix, shot from the hip just to muffle some of the most 
aggressive complaining.

It may have been the initial (terse and defensive?) wording in his first 
posts about it (I don't remember), or the choice of word "static", which 
yields a truly obscure statement that simply forces you to RTFM.

I've been against it, especially when "import a.b.c.d as f" looks both 
nice, is short, and is unavoidably clear and obvious, without RTFM.

-----

Having said the above, I'm starting to dither. (Sorry guys, don't shoot me!)

Scenario A:

All importing is by default "static".
Alias is used to fetch symbols, and to fetch namespaces.
Non-static import is entirely removed from the language.

Questions:

Would this remove the issue of public/private import altogether?
Would this be (significantly) easier for Walter to implement?
Would this yield an entirely robust import system?

!! And please, let only QUALIFIED people here answer these, ok!

With this scenario, I assume (corrections welcome) the following:


// module a
void fooa(){};
void fooa2(){};
void fooa3(){};


// module b
import a;    // static, so nothing is visible without FQN
alias a ma;  // just because "a" is a long name in reality :-)
a.fooa();    // using the "long name"
ma.fooa();   // using the "short alias"
fooa();      // ERROR, fooa not in current namespace
alias ma.fooa3 f3 // just to bring it visible for "my clients"
alias ma.fooa3 fooa3 // same thing


// main.d
import b;

b.a.fooa();  // ok, since a.fooa does appear in b
b.a.fooa2(); // ERROR
b.ma.fooa2(); // ERROR
b.ma.fooa(); // ok, appears in b

alias b.ma b; // we want to use (potentially many) from b
b.fooa();     // ok, ma.fooa appears in b
b.fooa2();    // ERROR no ma.fooa2 in b
b.f3();    // ok, a.fooa3 brought visible explicitly in b
b.fooa3(); // ok, same thing
alias b.fooa3 fooa3; // so bring it here too
fooa3();      // now ok


Could it be that this actually is nuke proof?? Also, this of course 
means that /if/ a module exists solely for reimporting stuff from other 
modules, then all that stuff would have to be explicitly listed in it. 
But that's the price of robustness anyway.


Scenario A got long enough as is, so I skipped examining scenario B. It 
would have been about "import a.b.c as d" etc. Somebody else might want 
to write that one. ;-)

As to the three questios earlier in this post, scenario A does not at 
all touch the issue of module private top level stuff.

module h;
private int foo;
private class da
{ //...
}

I think _that_privacy_thing_ should be discussed totally separately from 
Scenario A/B stuff, since privacy is orthogonal to the A vs B *choice*. 
(Of course it is not orthogonal to module logic and protection as such, 
but it _is_ orthogonal to the A/B choice.)