Rioshin an'Harthen wrote:
> "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. 

Not bad.

Smart people tend to find adequate practices however the law of the land is!

Rioshin an'Harthen wrote:
> "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.

I also like the first version. I have no idea why someone would like to "hide" the FQN's.

-- 
Jari-Matti

jcc7 wrote:
> 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).

There, I made an initial version based on this thread.

Lucas Goss wrote:
> 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.

These three look best to me too.

Visible private (import) is definitely non-consistent with not importing at all. Luckily private members are visible, but not accessible and private imports are not visible nor accessible currently by design.

-- 
Jari-Matti