Import conflict resoultion

[Jari-Matti Mäkelä]

Bruno Medeiros wrote:
> Regan Heath wrote:
>> On Fri, 14 Jul 2006 08:29:59 +0300, Georg Wrede
>> <georg.wrede at nospam.org> wrote:
>> <snip>
>>> Out of these, I'd want #4 and #5 combined.
>>>
>>> Except that I don't understand the following:
>>>
>>>  > 5:
>>>  > Allow selective import of the exact symbol which is required.
>>>  > import std.string.find; //exact syntax may vary
>>>  >
>>>  > ..find(.. //calls std.string.find
>>>  >
>>>  > No symbols from std.string would be present in the "secondary
>>> namespace".
>>>  >
>>>  >
>>>  > Opinions/pros/cons on the various solutions
>>>  > -------------------------------------------
>>>  >
>>>  > 5:
>>>  >  - PRO,Solves the import conflict for the intended symbol.
>>>  >  - CON,Does NOT solve future symbol conflicts.
>>>
>>> It was stated that "No symbols from std.string would be present in
>>> the "secondary namespace". Therefore I don't understand the CON
>>> argument "Does NOT solve future symbol conflicts".
>>
>> I guess it can be argued either way. #5 does avoid future symbol
>> collisions (from std.string) but only by virtue of importing no other
>> symbols. In other words the cost of avoiding a collision is not having
>> access to other symbols. So, when you do want more access you have to
>> specify each and every symbol. This solution is too micro-management
>> for my liking.
>>
> 
> What do you mean "when you do want more access you have to specify each
> and every symbol"? You mean having to use FQN?

When selectively importing you only have access to the symbols that are
listed in the import statement - not. If you want to import yet another
symbol, you have to explicitly add it to the imports - every time. But
when using #4, new accessible symbols are automagically imported to a
secondary namespace).

-- 
Jari-Matti