Import conflict resoultion

[Regan Heath]

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.

> -----------------
>
> Anyhow, I officially want to
>
> 1: be able to import a module into an arbitrary namespace
>
>      import foo.bar.baz.gawk.gasp.stuff as crap;

#4

> or even
>
>      import foo.bar.baz.gawk.gasp.stuff as foo.bar.baz.gawk.gasp.stuff;
>      // if I so care to choose. ;-/

#4

> 2: be able to import arbitrary module-top-level-identifiers, without  
> importing the rest of the module
>
>      import da.njet.ruskiij.svesda.myfunc as f;

#5 + #4

> 3: retain compatibility with legacy D code
>
>      import foo.bar;  // All of both go to the "secondary name space",
>      import baz.baw;  // as hitherto. (With risk of conflict. :-)  )

None of the proposals affect the existing import behaviour.

> 1, 2 and 3 should all be usable in the same file!
>
>      import foo.fii.faa;
>      import doo.dii.daa.aFunc as df;
>      import boo.bii.baa as b;

No problem, the proposals are not mutually exclusive.

> So, Regan, you may count my contribution as you like, here I've just  
> presented what I honestly want, without careful regard [or precise  
> understanding] of the Numbered Categories.

You could add your support here:
http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
you can even add your own desired syntax.

> ################################
>
> And even here I have to beg, crawl, kiss A, threat, --- or just ask  
> Walter:
>
>     Pretty please, please do include the word "as" in the import  
> statement, please!
>
> I know that it's not needed (i.e., a space would do), I know there are  
> numerous other alternatives ":", "=", you-name-it.
>
> But for the educational motivations you _yourself_ brought up a couple  
> of messages ago, and for corporate code maintenance, or newbie fluency  
> issues (which nobody has yet brought up), please retain the word "as"  
> here.
>
> It really doesn't waste /that/ much of ink.

As Don said and I tend to agree..

"#4 would definitely need different syntax, with a clearer visual  
distinction from a traditional import. Whether it be "import alias  
std.string str;" or "import std.string as str;" or "import std.string =  
str;" -- I don't have a strong preference."
   -Don Clugston

Regan