import concerns (was Re: Historical language survey)

[kris]

Walter Bright wrote:
> 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.


As FatFreddy would have noted, "Well, I'll be dipped in dogshit ..."