import concerns (was Re: Historical language survey)

[Walter Bright]

kris wrote:
> 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?

Yes.

> ---
> 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.

What I don't like about that proposal is the same reason you didn't like 
the warning proposal above - you'd be forced to fully qualify all 
references to names within b.

> 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.

I like this one better, too.


> 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.