Import conflict resoultion

Don Clugston dac at nospam.com.au
Thu Jul 13 06:27:49 PDT 2006


Regan Heath wrote:
> Proposed solutions
> ------------------
> 3:
> Prevent import into the "secondary namespace", only allow FQN access. 
> (AKA "static import")
> static import std.string; //exact syntax may vary
> static import std.regexp; //exact syntax may vary
> 
> ..find(.. //error
> ..std.string.find(.. //ok
> ..std.regexp.find(.. //ok
> 
> "All 'static import' does is eliminate the "if the name is not found in 
> the current module, look in the imports" step. This has the effect of
> requiring the use of FQN's when referencing imports."
>  - Walter
> 
> 4:
> Import into a custom namespace, eg.
> import std.string str; //exact syntax may vary
> import std.regexp;
> 
> ..str.find(.. //calls std.string.find
> ..find(.. //calls std.regexp.find
> 
> This method should also prevent import into the "secondary namespace".


Thanks, Regan. Indeed this is an attempt at conflict resolution in both 
meanings. Well done.

Seems to me that one of Walter's key non-negotiables is to ensure that:
------------
import std.stdio;

void main()
{
    writefln("Hello, world!");
}
------------
still works. Hopefully all of us can see the importance of that.

Personally, I don't have a strong objection to #3, if it was combined 
with default private imports, we wouldn't have to type "private static 
import" all the time, which would IMHO be unacceptable.

However, unlike Kris, I don't have any experience with working with 
really large projects in D (or any language at all, actually) -- so I'll 
trust Kris on the need for #4.

#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. I don't think there would be 
any need for it to prevent FQN access.

But really, I'll be happy just as long as we're not left with only #1 
and #2. I'm delighted that this fundamental issue is finally getting 
attention; I'm disappointed at how heated the discussion became.

Thanks again, Regan.



More information about the Digitalmars-d mailing list