Import conflict resoultion

[Bruno Medeiros]

Regan Heath wrote:
> On Sat, 15 Jul 2006 10:59:13 +0100, Bruno Medeiros 
> <brunodomedeirosATgmail at SPAM.com> wrote:
>> Jari-Matti Mäkelä wrote:
>>> 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).
>>>
>>
>> I didn't understand that "- not." in the first statement. I'm assuming 
>> it wasn't supposed to be there.
>>
>> So, yes, with selective import you only have access to the symbols 
>> that are listed in the import, but that is the same as #4's aliasing 
>> import:
>>    import std.string str; //exact syntax may vary
>> Here only the name 'str' is imported, if you want to import another 
>> symbol, you also have to add another import. Isn't that so?
> 
> No. #4 "import std.string str;" imports _all_ the symbols from 
> std.string into a namespace/prefix called "str". So, the difference is 
> this:

Which is the same to say that it imports the 'str' symbol (which is 
'std.string') into the current namespace.

> 
> import std.string str;
> str.find();    // ok, calls std.string.find
> str.tolower(); // ok, calls std.string.tolower
> 
> import std.string.find;
> find();    // ok, calls std.string.find
> tolower(); // error, std.string.tolower has not been imported.
> 
> Regan
> 

But I get your point. (did you see my comment about the universal 
selective import?)

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