Import conflict resoultion

[Regan Heath]

On Sat, 15 Jul 2006 12:43:16 +0100, Bruno Medeiros  
<brunodomedeirosATgmail at SPAM.com> wrote:
> 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.

Yes, I guess you could say that.. tho I don't really think of 'str' as  
being a symbol so much as an alias (another name) for a package/module.  
Would you call a package/module a symbol? I guess you could.

>>  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?)

Yes. I personally prefer the more explicit nature of #4, eg. "import  
std.string as string" mentions both "std.string" and "string" in the  
statement. "SELECTIVEIMPORT std.string" mentions only "std.string" but not  
(explicitly) "string". I think #4 is more obvious to the newcomer or the  
casual observer and the cost of typing a few more letters in one place.

Regan