Import conflict resoultion

[Jeremy]

In article <optcludog823k2f5 at nrage>, Regan Heath says...
>
>Here is my current understanding of the problems and solutions proposed to  
>date. Comments are welcome, including "enough already! the horse is dead!"  
>;)
>
>Regan
>
>
>Import conflict resolution
>--------------------------
>
>Assumptions
>-----------
>Imports are private by default (Walter seems to like this now?)
>
>
>Terminology
>-----------
>FQN = Fully Qualified Name
>
>
>Problems
>--------
>A:
>Importing 2 modules with the same symbol causes an immediate collision eg.
>import std.string;
>import std.regexp;
>
>..find(.. //error std.string.find or std.regexp.find
>
>B:
>Changes to a module at a later date may cause a collision at a later date.
>import a;
>import b;
>
>..foo(.. //calling a.foo.
>
>At later date symbol 'foo' is added to b and now the collision occurs.
>
>
>Current behaviour
>-----------------
>"How imports work is that first a name is searched for in the current  
>namespace. If it is not found, then it is looked for in the import list.  
>If it is
>found uniquely among the imports, then that is used. If it is in more than  
>one import, an error occurs"
>  - Walter
>
>"Import does not import names into the current namespace. It imports them  
>into a secondary namespace, that is looked in *only* if the name isn't
>found in the current namespace. Alias can then cherry-pick specific  
>symbols out of that secondary namespace and put them in the current  
>namespace,
>possibly renaming them along the way."
>  - Walter
>
>
>Current solutions
>-----------------
>1:
>import std.string;
>import std.regexp;
>alias std.string.find find;
>
>..find(.. //no error std.string.find is called
>
>2:
>import std.string;
>import std.regexp;
>
>..std.string.find(.. //no error FQN is used
>
>
>Opinions/pros/cons on the current solutions
>-------------------------------------------
>
>1:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
>  - CON,The alias is 'physically' seperate from the import.
>
>2:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
>  - CON,Causes more verbose code.
>
>Neither of these current solutions solves B.
>
>
>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".
>
>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
>-------------------------------------------
>
>3:
>  - PRO,Solves the import conflict for the intended symbol.
>  - PRO,Solves future symbol conflicts in the same module(s).
>  - CON,Causes more verbose code, using FQN all the time.
>
>4:
>  - PRO,Solves the import conflict for the intended symbol.
>  - PRO,Solves future symbol conflicts in the same module(s).
>
>5:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
>
>
>Conclusions, extra thoughts
>---------------------------
>
>The ideal solution IMO is #4, it solves both A and B in a simple, easy and  
>elegant(IMO) fashion something that cannot
>be said about the existing solutions #1 and #2.
>
>To the people who want FQN all the time.. You may view the proposed  
>solutions #3 and #4 as identical (in value to you).
>The deciding factor to my mind is that other people do not want to use FQN  
>all the time therefore #4 makes the most
>people happy. The interesting thing, is that FQN can be achieved with  
>soltion #4, note that:
>   import std.string std.string;
>
>would be FQN access, without! any further special syntax (like "static"),  
>to me this makes #4 better than #3
>even if you want to use FQN.
>
>Yes, it requires more typing but I don't think you can complain about  
>having to type the module name once more
>when you plan to type it 20+ more times in the course of the file, can you?
>
>FQN access is curently always present, but not required. However, with  
>solution #4 FQN access to the symbol is no longer
>ever required. It's presence results in code which can call the same  
>function in more than one way. This allows the code to
>be inconsistent for no gain (that I can imagine) therefore i think that  
>solution #4 should prevent FQN access to symbols.

This sounds like a very good summary -- I also like the #4 option :) So #4 +
private by default? Sounds good to me!

option[4].vote++;

- jeremy