In article <e8s9fk$2e3f$1@digitaldaemon.com>, Tom S says...
>
>Regan Heath wrote:
>> Something that has just occured to me WRT "Part-C" of my idea.. the restriction of allowing only one module is probably un-necessary if we assume a rule;
>> 
>> * If a module is a single word i.e. "mylib" it comes at the start of an import statement, eg.
>> 
>>   import mylib;
>> 
>> or
>> 
>>   import mylib,my.other.lib.copyFile;
>> 
>> etc.. and never after a "," eg.
>> 
>>   import my.other.lib.copyFile,mylib;
>> 
>> (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)
>> 
>> So, this allows multiple modules in the same import statement even allowing you to import them into the same named scope, some examples:
>> 
>>   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;
>> 
>> imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" from "your.lib".
>> 
>>   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;
>> 
>> imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" from "your.lib" into named scope "file".
>> 
>> Thoughts?
>
>Sorry, but I don't like it. I bet that every second coder new to the language would get totally confused by it.
>
>


I agree with, Tom.  Too confusing.

On Mon, 10 Jul 2006 02:01:31 +0000 (UTC), John Reimer <John_member@pathlink.com> wrote:
> In article <e8s9fk$2e3f$1@digitaldaemon.com>, Tom S says...
>>
>> Regan Heath wrote:
>>> Something that has just occured to me WRT "Part-C" of my idea.. the
>>> restriction of allowing only one module is probably un-necessary if we
>>> assume a rule;
>>>
>>> * If a module is a single word i.e. "mylib" it comes at the start of an
>>> import statement, eg.
>>>
>>>   import mylib;
>>>
>>> or
>>>
>>>   import mylib,my.other.lib.copyFile;
>>>
>>> etc.. and never after a "," eg.
>>>
>>>   import my.other.lib.copyFile,mylib;
>>>
>>> (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)
>>>
>>> So, this allows multiple modules in the same import statement even
>>> allowing you to import them into the same named scope, some examples:
>>>
>>>   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;
>>>
>>> imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"
>>> from "your.lib".
>>>
>>>   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;
>>>
>>> imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"
>>> from "your.lib" into named scope "file".
>>>
>>> Thoughts?
>>
>> Sorry, but I don't like it. I bet that every second coder new to the
>> language would get totally confused by it.
>>
>>
>
> I agree with, Tom.  Too confusing.

Really? :(

I mean, I don't see importing specific symbols as something a 'new' coder would do.. For example 'in my imaginary world' I see mr new coder...

1. starting with hello world, eg.

--[helloworld.d]--
import std.stdio;
void main()
{
  writefln("Hello World");
}

2. Moving on to import his own module eg.

--[mymod.d]--
void sayHello() { writefln("Hello World"); }

--[helloworld.d]--
import std.stdio,mymod;
void main()
{
  sayHello();
}

which will all work fine, no problems.

3. It's when he starts to think.. "I just need writefln why not code it like this" ..

--[mymod.d]--
void sayHello() { writefln("Hello World"); }

--[helloworld.d]--
import std.stdio.writefln,mymod;
void main()
{
  sayHello();
}

that he'll get an error.

In short, it's only a problem if you import a specific symbol in the same statement as a module which has no package (no "." in the module name/path/whatever)

Regan

More random musings.. if we have a syntax that reads:

import std.stdio as foo;

which imports the symbols in std.stdio into a namespace called 'foo', preventing access as just "writefln" requiring "foo.writefln" then what happens in a case like this:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as foo;

void main() {
  mixin foo;
}

?

Regan

In article <optcgd2ruo23k2f5@nrage>, Regan Heath says...
>
>More random musings.. if we have a syntax that reads:
>
>import std.stdio as foo;
>
>which imports the symbols in std.stdio into a namespace called 'foo', preventing access as just "writefln" requiring "foo.writefln" then what happens in a case like this:
>
>--[a.d]--
>import std.stdio;
>template foo { writefln("Hello World"); }
>
>--[b.d]--
>import std.stdio as foo;
>
>void main() {
>   mixin foo;
>}
>
>?
>
>Regan


Well, as far as I can see you should get an error telling you that foo is not a template. Now if you meant for the first line in [b.d] to read:

import a as foo;

Then I think we have a different issue. But since the programmer when through the trouble of importing into a named scope, this should be a no braner. In order to access the foo template , he needs to code explicitly.

:--[b.d]--
:import a as foo;
:
:void main() {
:   mixin foo;     // Error, foo is not a template
:   mixin foo.foo; // Ok
:}

Andrew

On Mon, 10 Jul 2006 11:04:39 +1200, Regan Heath wrote:

> Sub-thread for discussions

What are the problems that this discussion is trying to solve?

I submit these problems:

Problem A: How does one write code to tell readers of source code (people and IDEs) which module a referred to member exists in?

  Example:
      import aaa;
      import bbb;
      ...
      funcA(); // Is this in aaa, bbb, or the current module?

Problem B: How does one disambiguate identically named accessible members that happen to be in the same scope and whose signatures match?

      import aaa;
      import bbb;
      ...
      funcB(); // Is this calling the funcB in aaa, or the one in bbb?

Problem C: How does one force the use of Fully Qualified Name references?

There exists in the current D, techniques to solve problems A and B, but not C.

One can use a simple Fully Qualified Name syntax or the alias syntax to
resolve (A) and (B).

      import aaa;
      import bbb;
      aaa.funcA();
      bbb.funcB();

or

      import aaa;
      import bbb;
      alias aaa.funcA funcA;
      alias bbb.funcB funcBb;
      alias aaa.funcB funcBa;
      ...
      funcA;
      funcBb();

But why would these solutions need improving?

I think it is because they are not efficient from a code writer and reader's point of view. If one is forced to always use FQN, it increases the burden on coders and readers because there are more characters to process and much of those are redundant. The alias technique is a partial solution as it significantly reduces clutter, but it is still not optimal because it causes a redundant typing and reading to be done, and has the potential to increase maintenance costs if the alias and import statements are separated in the source code.

A better syntax would remove redundancy and localize the declarations for easier maintenance. Additional constraints would be to minimize the introduction of new keywords so as to avoid clashing with existing source code, and to permit backward compatibility for existing programs.

      import in std.string
              split,
              find alias find_str;
      import in bbb
              find alias find_re;
      ...
      split(. . .);
      find_re(. . .);

The "in" keyword would signal to the compiler that restricts imported names to only the list of members named after the module, and thus all other public members in the module are not allowed to be accessed. The "alias" keyword gives the imported member a new identity within the current module.

In order to force the use of FQN, an additional qualifier, or form of the import statement, is required because this is independent of the restricted importing concept.

 static import std.string; // All references must use FQN.
 static import in std.regexp find; // Only 'find' is imported and needs a
FQN.
 static import in std.stdio writefln alias print;

 . . .
 std.string.find( . . . );  // okay
 std.regexp.find( . . . );  // okay
 std.regexp.replace(. . .); // not okay (name not imported).
 std.stdio.print(. . .);  // okay
 print(. . .) // not okay as static import requested.


The "static" keyword (yes I know ... another overloading ... sigh) tells
the compiler that the names (and any aliases) in the imported module are
fixed (static) and must be referenced via a FQN.

A possible further optimization to support FQN would be to allow an alias for the *package.module* name as a whole to allow easier maintenance.

 static import std.string alias s;
 import std.regexp alias r;

 s.replace( . . . );
 r.replace( . . . );


All these forms could be used in conjunction with each other and with existing code.

IMPORT :: [static] import MODULENAMELIST;
MODULENAMELIST :: IMPORTMODULE [, MODULENAMELIST]
IMPORTMODULE :: [in] MODULENAME [alias ID] [MEMBERLIST]
MEMBERLIST :: IMPORTMEMBER [, MEMBERLIST]
IMPORTMEMBER:: ID [alias ID]


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 12:33:51 PM

On Mon, 10 Jul 2006 03:43:07 +0000 (UTC), Tyro <Tyro_member@pathlink.com> wrote:
> In article <optcgd2ruo23k2f5@nrage>, Regan Heath says...
>>
>> More random musings.. if we have a syntax that reads:
>>
>> import std.stdio as foo;
>>
>> which imports the symbols in std.stdio into a namespace called 'foo',
>> preventing access as just "writefln" requiring "foo.writefln" then what
>> happens in a case like this:
>>
>> --[a.d]--
>> import std.stdio;
>> template foo { writefln("Hello World"); }
>>
>> --[b.d]--
>> import std.stdio as foo;
>>
>> void main() {
>>   mixin foo;
>> }
>>
>> ?
>>
>> Regan
>
>
> Well, as far as I can see you should get an error telling you that foo is not a
> template. Now if you meant for the first line in [b.d] to read:
>
> import a as foo;
>
> Then I think we have a different issue. But since the programmer when through
> the trouble of importing into a named scope, this should be a no braner. In
> order to access the foo template , he needs to code explicitly.
>
> :--[b.d]--
> :import a as foo;
> :
> :void main() {
> :   mixin foo;     // Error, foo is not a template
> :   mixin foo.foo; // Ok
> :}

Ooops, my bad example, what I meant was:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as bar;
import a;

void main() {
  mixin foo;
}

I accidently called the template and import named scope the same thing.

Regan

In article <optcgh6iaa23k2f5@nrage>, Regan Heath says...
>
>On Mon, 10 Jul 2006 03:43:07 +0000 (UTC), Tyro <Tyro_member@pathlink.com> wrote:
>> In article <optcgd2ruo23k2f5@nrage>, Regan Heath says...
>>>
>>> More random musings.. if we have a syntax that reads:
>>>
>>> import std.stdio as foo;
>>>
>>> which imports the symbols in std.stdio into a namespace called 'foo', preventing access as just "writefln" requiring "foo.writefln" then what happens in a case like this:
>>>
>>> --[a.d]--
>>> import std.stdio;
>>> template foo { writefln("Hello World"); }
>>>
>>> --[b.d]--
>>> import std.stdio as foo;
>>>
>>> void main() {
>>>   mixin foo;
>>> }
>>>
>>> ?
>>>
>>> Regan
>>
>>
>> Well, as far as I can see you should get an error telling you that foo
>> is not a
>> template. Now if you meant for the first line in [b.d] to read:
>>
>> import a as foo;
>>
>> Then I think we have a different issue. But since the programmer when
>> through
>> the trouble of importing into a named scope, this should be a no braner.
>> In
>> order to access the foo template , he needs to code explicitly.
>>
>> :--[b.d]--
>> :import a as foo;
>> :
>> :void main() {
>> :   mixin foo;     // Error, foo is not a template
>> :   mixin foo.foo; // Ok
>> :}
>
>Ooops, my bad example, what I meant was:
>
>--[a.d]--
>import std.stdio;
>template foo { writefln("Hello World"); }
>
>--[b.d]--
>import std.stdio as bar;
>import a;
>
>void main() {
>   mixin foo;
>}
>
>I accidently called the template and import named scope the same thing.
>
>Regan

In this case I assume that you are concerned with conflicts that may be generated between both imports of std.stdio in [a.d] and [b.d]. I don't see much of a problem with this either.

Since [a.b] imports std.stdio publicly and into a global scope (or is that file level scope?) anything that imports [a.b] will be able to access std.stdio methods directly.

[b.d] however, imports std.stdio into a named scope. Thus all access to methods identified in that particular scope should be prefexed accordinly. There should be no conflicts.

:--[b.d]--
:import std.stdio as bar;
:import a;
:
:void main() {
:   mixin foo;
:   writefln("something"); // Accesses method imported in [a.d]
:   bar.writefln("somethingElse"); // Accesses method imported in [b.d]
:}

Unless of course I have completely missed the intent of importing into named scopes.

Andrew

Regan Heath wrote:

> Part-E
> import this.is.the.lib as this.is.the.lib;

I don't like this syntax. Retyping the same things twice is not a good idea. It's syntactic overhead.

FQN import is common and it should be simple, so previous proposals like "static import" and "fqnimport" seem more appealing to me (though I would personally prefer "using" keyword).


-- 
AKhropov

In article <optcf2eoqc23k2f5@nrage>, Regan Heath says...
>
>Sub-thread for ideas.

I'm not thrilled about the prospect of reusing static for yet another purpose, but I don't think that we need to add "from" or "as" to the keyword list either.

Instead of "import fooTooLong.reallyTooLong as fooShort;"

we could re-use an operator:
"import fooTooLong.reallyTooLong = fooShort;"

I like it, but it could just be me.

I think someone else suggested this already, but I like it, too: "import fooTooLong.reallyTooLong alias fooShort;"

Now, I'm really brainstorming...

Or one of these might work:
"import fooTooLong.reallyTooLong fooShort;" (no keyword needed at all)
"import fooTooLong.reallyTooLong for fooShort;"
"import fooTooLong.reallyTooLong out fooShort;"
"import fooTooLong.reallyTooLong in fooShort;"


Or maybe even use one of these to force FQN (static is already used for enough
different things):
"import final fooTooLong.reallyTooLong;"
"import do fooTooLong.reallyTooLong;"
"import void fooTooLong.reallyTooLong;"


Just throwing out ideas...

jcc7

jcc7 wrote:
> In article <optcf2eoqc23k2f5@nrage>, Regan Heath says...
> 
>>Sub-thread for ideas.
> 
> 
> I'm not thrilled about the prospect of reusing static for yet another purpose,
> but I don't think that we need to add "from" or "as" to the keyword list either.
> 
> Instead of "import fooTooLong.reallyTooLong as fooShort;"
> 
> we could re-use an operator:
> "import fooTooLong.reallyTooLong = fooShort;"
> 
> I like it, but it could just be me.

I think its a pretty neat idea, actually.  Although, maybe it should be the colon instead?

# import fooTooLong .reallyTooLong : fooShort ;

> I think someone else suggested this already, but I like it, too:
> "import fooTooLong.reallyTooLong alias fooShort;"

The placement of the 'alias' keyword throws me off pretty bad...  I can't help thinking it should be somewhere at the beginning, but then I don't like whitespace in my 'import' statement either.  I'm too picky!

> Now, I'm really brainstorming...
> 
> Or one of these might work:
> "import fooTooLong.reallyTooLong fooShort;" (no keyword needed at all)
> "import fooTooLong.reallyTooLong for fooShort;"
> "import fooTooLong.reallyTooLong out fooShort;"
> "import fooTooLong.reallyTooLong in fooShort;"

The 'in' case makes some sense, but the other ones... erm...

> 
> Or maybe even use one of these to force FQN (static is already used for enough
> different things):
> "import final fooTooLong.reallyTooLong;"
> "import do fooTooLong.reallyTooLong;"
> "import void fooTooLong.reallyTooLong;"

Do? Do?? Do?!  ;)  Why not 'default'?  Or 'typedef'?  (Actually, that'd be cute.)

I still think we need something like an 'fqn' keyword to accomplish this.  Or possibly the elsewhere-proposed 'fqnimport' statement.

-- Chris Nicholson-Sauls