Import concerns revisited

[Dave]

Bruno Medeiros wrote:
> xs0 wrote:
>> Tom S wrote:
>>
>>> Another downside is that, the selective import using the 'with' 
>>> construct only imports these symbols into the current scope, while 
>>> 'static import' allows you to access all symbols from the imported 
>>> module if you use a fully qualified name. This is as evil as the 
>>> "'private', yet not private" symbols in modules.
>>
>> While I support improving import (particularly allowing import of 
>> single symbols), I think you're exaggerating here. There is actually 
>> nothing wrong if all FQNs from a module are accessible (if private 
>> worked, anyway ;), as most all of the problems arise only with 
>> unqualified names.. In fact, some languages (e.g. Java) allow access 
>> via FQN without even specifically importing anything, and I never 
>> heard referred to that feature as evil before :)
>>
>> That private symbols are visible is pure evil, though :) They should 
>> behave as if they don't exist to outside their module, that being the 
>> whole point of tagging something as private.
>>
>>
>> xs0
> 
> I must strongly reinforce this statement. There is nothing wrong with 
> FQNs being automatically available in a program (it's how Java and C# 
> work), in fact, I strongly prefer this behavior and am planning to 
> implement it in D when we get the FQN import. 
> (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)
> 

The one problem with that may be compilation speed. I suspect that a big 
part of  Java's compile-time and load-time problems are because of all 
the symbol loading it has to do for a typical class path to enable 
things like automatic FQN availability. At the command line, the C# 
compiler actually isn't that fast either for small programs, but in the 
IDE it seems fast because all this stuff is pre-loaded.

Once you implement it, I'd be interested in how it effects compilation 
speed. Maybe DWT would be a good test bed for that too - there is 
already an all.d for that that could be easily copied and changed.

If it doesn't effect things too much, then I think the Phobos distro. 
could use an "allfqn.d" too just for the simple expedient it would offer 
for teaching, and maybe things like replacing common Perl and Python 
scripts with D. Maybe "all.d" is too much, and could just be replaced 
with "commonfqn.d" + things like "mathfqn.d", etc?