Import concerns revisited

[Walter Bright]

kris wrote:
> Walter Bright wrote:
>> Dave wrote:
>>
>>> I'm not sure what exactly Kris said, but imports are ubiquitous.
>>
>>  > Not used as much as loops of course, but they are used in every 
>> program.
>>
>> Yes, they are ubiquitous. But the renaming of imported symbols? I'm 
>> not convinced that is at all ubiquitous, or that it is very desirable 
>> in any but unusual cases.
> 
> ??
> 
> I suspect you are very confused about what is actually being asked for. 
> Is that the case? Perhaps you'd like to note what it is that you think 
> is being proposed?

You prefer:

	with Foo import bar as abc;

instead of:

	static import Foo;
	alias Foo.bar abc;


>>>  > 2) how much power it adds
>>> It adds the ability to import specific symbols - a quite powerful 
>>> addition to import I think.
>> But that power already exists. 
> One can import only specific symbols at this time? Really?

Import does not import names into the current namespace. It imports them 
into a secondary namespace, that is looked in *only* if the name isn't 
found in the current namespace. Alias can then cherry-pick specific 
symbols out of that secondary namespace and put them in the current 
namespace, possibly renaming them along the way. (Python's documentation 
calls that "binding" a name into the local symbol table, but it's the 
same thing.)

With 'static import', the names aren't even put into the secondary 
namespace. Unaliased, they can only be accessed as FQN's. An alias can 
then be used to bind individual symbols into the current namespace.

(*) And yes, you can still access the other names in the static import 
via FQN's. A couple posters thought that might be a problem, but:
1) I doubt many are going to accidentally type in a FQN;
2) FQN's are not going to produce name collisions unless you happen to 
name your symbols the same as the topmost package name, which is just 
not realistically going to be a problem.


>> The discussion is now about whether two statements should be combined 
>> into one or not. The power is the same.
> Again, please refer to Sean's post from yesterday.

I did (thanks for the direct link, Sean). The two proposals are 
semantically identical (*), and I don't see anything in Sean's post to 
indicate otherwise. It seems to me that Sean agreed that the difference 
is aesthetic, not functional.