• Lucas Goss (26/26) Jul 12 2006 There seems to be some overlap of issues, so maybe a collection of
• Lucas Goss (5/7) Jul 12 2006 Forgot to add:
• Jeremy (8/34) Jul 12 2006 In my FreeUniverse game, 90% of my imports are "private", just because t...
• Lucas Goss (10/13) Jul 12 2006 static imports are a way to keep imported names out of the namespace.
• Jeremy (5/18) Jul 12 2006 Hrm, I don't think I like that idea... there are "static ints" and "stat...
• Lucas Goss (5/18) Jul 12 2006 I like these three. The visible private makes no sense and like someone
• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (7/25) Jul 12 2006 These three look best to me too.
• Lucas Goss (11/11) Jul 12 2006 Question about prefix-importing...
• Rioshin an'Harthen (17/25) Jul 12 2006 My opinion is: never ever forbid the use of FQN's to use a symbol.
• Georg Wrede (3/40) Jul 12 2006 Not bad.
• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (5/40) Jul 12 2006 I also like the first version. I have no idea why someone would like to
• Lucas Goss (5/12) Jul 12 2006 Additional problems (discussed in "import RFC"):
• jcc7 (7/19) Jul 12 2006 It can be kind of difficult to keep of with this growing list of concern...
• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (2/5) Jul 12 2006 There, I made an initial version based on this thread.

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

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

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

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

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 :)

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

=?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

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

"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. 

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!

=?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

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

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

=?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.