|Posted by Georg Wrede||PermalinkReply|
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!)
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.
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
// 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
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.
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.)