the point of selective importing

[Don Clugston]

Ameer Armaly wrote:
> "Bill Baxter" <Bill_member at pathlink.com> wrote in message 
> news:e8v32s$65i$1 at digitaldaemon.com...
>> In article <e8urqt$2vb2$1 at digitaldaemon.com>, Ameer Armaly says...
>>> ...
>>> It might just be me, but IMHO you're trying to mix apples with oranges;
>>> either you want fully qualified imports or you want standard imports.  If
>>> you desperately want to mix them, then I agree with Walter in that aliases
>>> should be just fine; anyone with half a brain will put them right near the
>>> import where they can be seen; anyone who doesn't do that is just a bad
>>> coder.
>> Good points.
>>
>> But
>> A) renaming modules is pretty common once you allow FQN import.
>>
> Why?  Isn't the point of fqn importing to prefix the module name?  This goes 
> back to the idea that either you import the module in to the global 
> namespace or you deal with the full name; I just don't see this being done 
> very often, especially with well known libraries.
>> static import module.with.a.long.name.string;
>> alias module.with.a.long.name.string Str;
>>
>> It would be nice to be able to put those into one statement so that the 
>> module
>> name doesn't have to be typed in twice.
>>
>> B) Sometimes you want to keep your namespace clean except for a handful of
>> specific symbols from some module:
>>
>> static import module.with.a.long.name;
>> alias module.with.a.long.name.foo Foo;
>> alias module.with.a.long.name.bar Bar;
>> alias module.with.a.long.name.baz Baz;
>>
>> That would also be easier to read,write, and maintain if 
>> module.with.a.long.name
>> didn't appear 4 times.
>>
>> Granted, you could do:
>> static import module.with.a.long.name;
>> alias module.with.a.long.name MWLN;
>> alias MWLN.foo Foo;
>> alias MWLN.bar Bar;
>> alias MWLN.baz Baz;
>>
>> which is better, but the full module name still appears twice, and I 
>> didn't
>> really want MWLN or module.with.a.long.name in my namespace to begin with.
>>
> Why not then just import the whole module in to the namespace?  It's not as 
> if the namespace is something you actually look and see "god this is 
> cluttered with junk," so I really don't see the point.  If a module is 
> written in such a way as to force you to go to these lengths to optimally 
> use it then it's badly written.

Because the problems only really happen when you import more than one 
module. The existing system copes well with a single import. If 
something in the import has the same name as the function in your 
primary file, they don't conflict, because the primary namespace is 
searched before the imported one. But, if you import from two files, you 
can have a naming conflict in the secondary namespace. You have no 
choice -- you *have* to use FQN.


Currently, I would maintain that it is not possible to use unqualified 
names safely in any file which imports more than one module. 'static 
import' would make it always safe to use one non-qualified module, and 
an arbitrary number of FQN modules. In any other configuration, adding a 
new function to a module can break existing code which imports it.