Import concerns revisited

[xs0]

>>> 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.
>>
>> I don't think it would affect compilation speed at all. Stuff only 
>> needs to be looked up when referenced, and if referenced, it needs to 
>> be imported anyway.
>>
> 
> I don't think that is correct for the reference compiler, because 
> Walter's 'static import' proposal still imported the entire module 
> (probably because the way the compiler works now is to 'load' an entire 
> imported module, IIRC).

Hmm, we were talking about the possibility of implicit importing when 
using FQNs (I think ;)

But it's the same - whatever causes an import (current import, static 
import, implicit import by FQN, single member import), the processing of 
a module takes about the same time, because it's basically doing the 
same thing in every case.. OK, perhaps an implicit import would need a 
few file accesses to determine which part of the FQN is the actual 
module/file, but in the grand scheme of things, that should take a 
negligible amount of time...

Hmm.. considering that imports can be placed anywhere and module names 
aren't allowed to conflict with anything, it should be quite simple to 
support "auto-static-importing" on encountering an unknown FQN.. That 
would allow the following without any new syntax at all:

alias some.module.name smn; // imports and renames a whole module
alias some.module.name.Class smnClass; // imports a single member

std.stdio.writefln("I just need this function from stdio");


xs0