import concerns (was Re: Historical language survey)

[kris]

Walter Bright wrote:
> What can be done is something like add a warning whenever a name is 
> found using the second-class import lookup, rather than using an alias 
> or a fully qualified lookup. Then, you'll be able to easily purge your 
> code of any such, and be confident that adding other modules will not 
> break your existing code.

I perhaps don't quite follow that completely. But it sounds like you're 
saying all names would have to be fully qualified at all times, unless 
they're declared within the enclosing module? If not, then forgive me 
for not following correctly.

If so, I think that would overly restrictive, and would perhaps 
encourage a slew of aliases just to make things work correctly. I think 
that would be detrimental, since those who wish to write Q&D code would 
find themselves prejudiced against. The "import x.y.z as foo;" syntax 
suggested is purely an option for those who care about ensuring the 
namespaces are fully isolated ~ and is a clean way to do it for an 
entire module as a time. e.g. with the "as" syntax, the following would 
operate without conflict:

---
module a;

int foo() {...}

---
module b;

int foo() {...}

---
module main;

import a;
import b as other;

void main()
{
	foo();       // a.foo
	other.foo()  // b.foo;
}

In this trivial example, you could do the same with an alias. However, 
an alias would /potentially/ be needed for every symbol within module b, 
whereas the "as" handles all of that cleanly. Consider the effort to 
manually alias each symbol from each imported modules that may 
potentially change over time? Import "as" does it cleanly instead.

However, I think this next option is preferable:


> What can also be done is extend the import declaration to allow the .'s 
> to continue so that specific symbols can be imported.

Now that would be great. I believe selective-importing (as an option) 
would be a boon in a number of ways ~ and would resolve this issue quite 
elegantly.

Neither of these would have any effect on existing code, so there's no 
concern over backward compatability. But it could be argued that the 
latter case is notably more explicit, and perhaps avoids an additional 
renaming step within the compiler.