Import conflict resoultion
Dave
Dave_member at pathlink.com
Thu Jul 13 11:20:18 PDT 2006
Jeremy wrote:
> In article <e95lvr$2t28$1 at digitaldaemon.com>, Dave says...
>> Don Clugston wrote:
>>> 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.
>>>
>> import std.string as string; // Ok, but new keyword
>
> I like this one the best. It is so "readable" while not being too wordy.
>
>> import string = std.string; // Ok: concise, distinct, consistent and
>> logically accurate.
>
> That just looks odd to me... it looks like "import" is some data type, and your
> assigning some value "std.string" to "string". It also is very different from
> 'normal' import lines:
>
> import std.string;
> import std.string as str;
>
> vs.
>
> import std.string;
> import str = std.string;
>
> Putting "as str" at the end of the import is more intuitive than putting a "str
> =" in the middle of the import line...
>
> disclaimer: add IMHO to all my statements :)
>
Seems others agree with you - note your preferences here if you want:
http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
More information about the Digitalmars-d
mailing list