There seems to be some overlap of issues, so maybe a collection of issues and resolutions would help focus the discussion? I'm just listing what appears to be suggested (and what I remember), so feel free to add or correct where necessary. And maybe the wiki could even help facilitate this?

problems:
  -Name collisions local (owned by programmer)
  -Name collisions external (caused by outside libraries)
  -Too wordy (causing inconsistency and maintainability problems)
  -Default gotchas (cause problems or make maintainability harder)

solutions:

-static import:
  -tries to solve problem of name collisions, requiring FQN's

-alias currently:
  -tries to solve problem of being too wordy, allowing a shorter name

-selective-importing:
  -tries to solve problem of name collisions

-prefix-importing proposed (import std.string alias str)
  -tries to solve problem of name collisions

-private invisible (not visible to importing modules)
  -tries to solve problem of name collisions by hiding modules
  -tries to make private more intuitive

-private by default
  -tries to solve the problem of name collisions
  -tries to solve the problem of default gotchas

Lucas

Lucas Goss wrote:
> solutions:
> ...

Forgot to add:

-static import by default
  -tries to solve problem of name collisions.

Lucas

In article <e9303p$qdr$1@digitaldaemon.com>, Lucas Goss says...
>
>There seems to be some overlap of issues, so maybe a collection of issues and resolutions would help focus the discussion? I'm just listing what appears to be suggested (and what I remember), so feel free to add or correct where necessary. And maybe the wiki could even help facilitate this?
>
>problems:
>   -Name collisions local (owned by programmer)
>   -Name collisions external (caused by outside libraries)
>   -Too wordy (causing inconsistency and maintainability problems)
>   -Default gotchas (cause problems or make maintainability harder)
>
>solutions:
>
>-static import:
>   -tries to solve problem of name collisions, requiring FQN's
>

I'm new in this discussion :) What are "static imports" and FQN's?

>-alias currently:
>   -tries to solve problem of being too wordy, allowing a shorter name
>
>-selective-importing:
>   -tries to solve problem of name collisions
>
>-prefix-importing proposed (import std.string alias str)
>   -tries to solve problem of name collisions
>
>-private invisible (not visible to importing modules)
>   -tries to solve problem of name collisions by hiding modules
>   -tries to make private more intuitive
>
>-private by default
>   -tries to solve the problem of name collisions
>   -tries to solve the problem of default gotchas
>
>Lucas

In my FreeUniverse game, 90% of my imports are "private", just because things seem to conflict less that way (However, I had a ton of "std" name conflicts, so I had to make those modules public at some base module). So if I had to vote for something, I think I would go for "private by default", and maybe that "import <module> alias <name>" syntax too :)

- jeremy

Lucas Goss wrote:
> solutions:
> 
> -prefix-importing proposed (import std.string alias str)
>   -tries to solve problem of name collisions
> 
> -private invisible (not visible to importing modules)
>   -tries to solve problem of name collisions by hiding modules
>   -tries to make private more intuitive
> 
> -private by default
>   -tries to solve the problem of name collisions
>   -tries to solve the problem of default gotchas
> 

I like these three. The visible private makes no sense and like someone else said, "is evil". And private by default along with prefix-importing seems to solve maintainability problems as well as being simple.

Lucas

Jeremy wrote:
> 
> I'm new in this discussion :) What are "static imports" and FQN's?
> 

static imports are a way to keep imported names out of the namespace. FQN's means fully qualified names. It works like this:

static import std.stdio;

void main(char[][] args)
{
  writefln("hello"); // illegal, writefln isn't in namespace
  std.stdio.writefln("hello"); // ok, using fully qualified name
}

Lucas

Question about prefix-importing...

Is this suggested as importing the fully qualified name as well? If so then I'd change the solution to too wordy, as the current alias already does this, just on a separate line correct? Which is it:

1 -prefix-importing (with fully qualified name)
    -tries to solve problem of being too wordy (a one line alias import)

2 -prefix-importing (replacing fully qualified name)
    -tries to solve problem of name collisions

Writing all this out I can see how people get confused by what is being proposed and what is being argued against.

Lucas

In article <e931aa$t1j$1@digitaldaemon.com>, Lucas Goss says...
>
>Jeremy wrote:
>> 
>> I'm new in this discussion :) What are "static imports" and FQN's?
>> 
>
>static imports are a way to keep imported names out of the namespace. FQN's means fully qualified names. It works like this:
>
>static import std.stdio;
>
>void main(char[][] args)
>{
>   writefln("hello"); // illegal, writefln isn't in namespace
>   std.stdio.writefln("hello"); // ok, using fully qualified name
>}
>
>Lucas

Hrm, I don't think I like that idea... there are "static ints" and "static ifs" that are unrelated to "static imports"... just seems very unintuitive. I don't know all of the previous arguments for/against it, but it doesn't get my (initial) vote :)

Lucas Goss wrote:
> 
> problems:
>   -Name collisions local (owned by programmer)
>   -Name collisions external (caused by outside libraries)
>   -Too wordy (causing inconsistency and maintainability problems)
>   -Default gotchas (cause problems or make maintainability harder)
> 

Additional problems (discussed in "import RFC"):
  -Modules inheriting 'grandparent' is unexpected with private
  -Name collisions from a module not imported (inherited module)

Lucas

In article <e93bom$1l79$1@digitaldaemon.com>, Lucas Goss says...
>
>Lucas Goss wrote:
>> 
>> problems:
>>   -Name collisions local (owned by programmer)
>>   -Name collisions external (caused by outside libraries)
>>   -Too wordy (causing inconsistency and maintainability problems)
>>   -Default gotchas (cause problems or make maintainability harder)
>> 
>
>Additional problems (discussed in "import RFC"):
>   -Modules inheriting 'grandparent' is unexpected with private
>   -Name collisions from a module not imported (inherited module)
>
>Lucas

It can be kind of difficult to keep of with this growing list of concerns (especially for those of us using the web interface).

You might want to start a new wiki page with this list of issues. You could call it: http://www.prowiki.org/wiki4d/wiki.cgi?ImportIssues (or whatever else you'd like to call it).

jcc7

"Lucas Goss" <lgoss007@gmail.com> wrote:
> Question about prefix-importing...
>
> Is this suggested as importing the fully qualified name as well? If so then I'd change the solution to too wordy, as the current alias already does this, just on a separate line correct? Which is it:
>
> 1 -prefix-importing (with fully qualified name)
>     -tries to solve problem of being too wordy (a one line alias import)
>
> 2 -prefix-importing (replacing fully qualified name)
>     -tries to solve problem of name collisions

My opinion is: never ever forbid the use of FQN's to use a symbol.

I tend to (in longer functions), if I've imported according to as follows

import module.with.a.long.name;
alias module.with.a.long.name mwln;

to write something akin to

module.with.a.long.name.foo();
// a few lines later
mwln.bar();

which helps readability - first time a symbol is used from a module, write the FQN of the module name, and after that, use the short alias.

In Java, I tend to do something like this. I import the symbols I require, and the first time in a longish method, I write the fully qualified name of the symbol, and only then the short form - this lets me, or anyone else reading the code, quickly in the same function/method see from where the symbol comes from, and isn't too much of a trouble when it comes to wordiness.