Import conflict resoultion

Tyro Tyro_member at pathlink.com
Sat Jul 15 03:31:25 PDT 2006


In article <e9ae71$d4j$1 at digitaldaemon.com>, Bruno Medeiros says...
>
>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! In selectively importing std.string.find you are only importing the find()
method from the module std.string. This allows you access to std.string.find()
but nothing else from that module.

| import std.string.find;
| 
| void main()
| {
|   char[] s = "Something to find";
|   find(s, "to"); // Ok
|   std.string.find(s, "find"); // Ok?
|   char[][] words;
|   words = std.string.split(s); // Illegal
| }

With option #4 you are importing the entire std.string module into a namespace
called "str" (or whatever else you'd like) and you have complete access to the
symbols from that module through str.

| import std.string as str;
| 
| void main()
| {
|   char[] s = "Something to find";
|   find(s, "to"); // Illegal
|   str.find(s, "to"); // Ok
|   std.string.find(s, "find"); // Illegal
|   str.find(s, "find"); // Ok
|   char[][] words;
|   wirds = split(s); // Illegal
|   words = std.string.split(s); // Illegal
|   words = str.split(s); // Ok
| }

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

Andrew Edwards





More information about the Digitalmars-d mailing list