www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import status

reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 12 2006
next sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Lucas Goss wrote:
 solutions:
 ...
Forgot to add: -static import by default -tries to solve problem of name collisions. Lucas
Jul 12 2006
prev sibling next sibling parent reply Jeremy <Jeremy_member pathlink.com> writes:
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
Jul 12 2006
parent reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 12 2006
parent Jeremy <Jeremy_member pathlink.com> writes:
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 :)
Jul 12 2006
prev sibling next sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 12 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
Jul 12 2006
prev sibling next sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 12 2006
parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"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.
Jul 12 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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!
Jul 12 2006
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
Jul 12 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 12 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
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
Jul 12 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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.
Jul 12 2006