Import conflict resoultion

[Bruno Medeiros]

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?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D