Hi all,

I just want to share some thoughts about modules and their import.

When we want to import a module we should decide on 2 things:

1) do we want to import names from the module to the local namespace?

2) do we want this import to be propagated to the files that include the module we import in?

In D the second question can be answered "no" by adding "private" modifier to
the import statement, but the first question is always answered "Yes".
I think it's not a good idea. My opinion is that notions
"I want to use a module" and "I want names in the module to be imported in the
current scope" should be separated.

Like in C++ we have (of course C++ don't have true modules but I want to show
an example):
---------------------------
#include <iostream>		// "Import" a module

using namespace std;		// import declarations in "std" in the current scope
---------------------------

So I would like to see a possibility to answer "no" to the first question and use fully qualified names if I want to avoid name conflicts.

So maybe default behavior of "import" should be changed (and later symbols could be imported to the current scope by some kind of "alias" statement) or an alternative declaration to import modules ("using" ?) could be added to mean "use declarations from the module but keep them in that module's namespace".

--------------------------------------------------------------------------------

Another thing I would like (maybe a beyond 1.0 feature) is that compiled modules should contain both the module interface and implementation so we don't need to have separate "d/di" interface files and "lib" with implementation.

When compiler finds an "import" declaration it finds a module (or maybe whole
package of modules in one file), imports its symbol table and also passes
module name to the linker so we don't have to pass module name as the linker's
parameter explicitly as it has already been declared in the source files.


-- 
AKhropov

On Wed, 28 Jun 2006 01:18:31 +1000, Andrei Khropov <andkhropov@nospam_mtu-net.ru> wrote:

>
> Hi all,
>
> I just want to share some thoughts about modules and their import.
>
> When we want to import a module we should decide on 2 things:
>
> 1) do we want to import names from the module to the local namespace?
>
> 2) do we want this import to be propagated to the files that include the module
> we import in?
>
> In D the second question can be answered "no" by adding "private" modifier to
> the import statement, but the first question is always answered "Yes".


I'm trying to make sure that I understand your terminology here.

By the phrase "import names from the module to the local namespace", I read that as saying that if names from an imported module come into the importing module's namespace, it would mean that the importing module cannot declare a name that is contained in the imported module - because that would be a duplicated name in the same namespace.

But that's not what happens with D so therefore I'm not sure what you mean by "import names from the module to the local namespace".

To access a name from an imported module that has the same name as a member in the importing module, you must qualify the imported name with the module name.

-----------EXAMPLE ---------
module mod1;
public int AA = 2;
----------------------------
module sample;
import std.stdio;
import mod1;
public real AA = 3.21;
void main()
{
    writefln("%s %s", AA, mod1.AA);
}
-----------------


Am I misunderstanding you?

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Wed, 28 Jun 2006 01:18:31 +1000, Andrei Khropov <andkhropov@nospam_mtu-net.ru> wrote:
> 
>>
>> Hi all,
>>
>> I just want to share some thoughts about modules and their import.
>>
>> When we want to import a module we should decide on 2 things:
>>
>> 1) do we want to import names from the module to the local namespace?
>>
>> 2) do we want this import to be propagated to the files that include the module
>> we import in?
>>
>> In D the second question can be answered "no" by adding "private" modifier to
>> the import statement, but the first question is always answered "Yes".
> 
> 
> I'm trying to make sure that I understand your terminology here.
> 
> By the phrase "import names from the module to the local namespace", I read that as saying that if names from an imported module come into the importing module's namespace, it would mean that the importing module cannot declare a name that is contained in the imported module - because that would be a duplicated name in the same namespace.
> 
> But that's not what happens with D so therefore I'm not sure what you mean by "import names from the module to the local namespace".
> 
> To access a name from an imported module that has the same name as a member in the importing module, you must qualify the imported name with the module name.
> 
> -----------EXAMPLE ---------
> module mod1;
> public int AA = 2;
> ----------------------------
> module sample;
> import std.stdio;
> import mod1;
> public real AA = 3.21;
> void main()
> {
>     writefln("%s %s", AA, mod1.AA);
> }
> -----------------
> 
> 
> Am I misunderstanding you?
> 
> --Derek Parnell
> Melbourne, Australia

I'm betting he means being able to import a module in a way that it's names (entities) are available only as fully-qualified names, and so the base names are not "imported" to the importing module namespace/scope. It's the FQN import.

Andrei, (and others) if you want to check out some previous discussion on this matter:
http://www.digitalmars.com/d/archives/digitalmars/D/28423.html

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:

> I'm betting he means being able to import a module in a way that it's names (entities) are available only as fully-qualified names, and so the base names are not "imported" to the importing module namespace/scope. It's the FQN import.
> 
> Andrei, (and others) if you want to check out some previous discussion on this matter:  http://www.digitalmars.com/d/archives/digitalmars/D/28423.html

Yes, you're right.
 Thank you for the link, I'm quite new to D so I haven't already read all the
40000+ newsgroup messages huh :-).


Basically your message is similar to mine in its subject but is much more detailed.

But anyway, as far as I can see Walter's opinion is unknown.
 Is he satisfied with the present situation?

-- 
AKhropov

On Wed, 28 Jun 2006 08:18:40 +1000, Andrei Khropov <andkhropov@nospam_mtu-net.ru> wrote:

> Bruno Medeiros wrote:
>
>> I'm betting he means being able to import a module in a way that it's names
>> (entities) are available only as fully-qualified names, and so the base names
>> are not "imported" to the importing module namespace/scope. It's the FQN
>> import.
>>
>> Andrei, (and others) if you want to check out some previous discussion on
>> this matter:  http://www.digitalmars.com/d/archives/digitalmars/D/28423.html
>
> Yes, you're right.

> But anyway, as far as I can see Walter's opinion is unknown.
>  Is he satisfied with the present situation?

I believe so.

The curent situation is a syntax shortcut. No one is prevented from using FQN syntax, and in fact I try to use that form in my code, with the main exception being 'writefln' of course ;-)

The benefit I can see from the shortcut form is that one can change modules without having to change references to members in that module, whereas with FQN usage one has to do a global find/replace over all your source code.

The cost of not using FQN though is it does not keep well over time in terms of reading the code and have an understanding of it. Plus you can get caught out sometimes when introducing another import that causes name clashes.

I'm not an advocate of either style of coding and I won't dictate to others either on this matter. I have a preference, as my fellow coders also have a preference, which may be different, and I'm okay with that.

Why do you think that FQN syntax is demonstrable better than the current shortcut syntax?

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell schreef:
> On Wed, 28 Jun 2006 08:18:40 +1000, Andrei Khropov <andkhropov@nospam_mtu-net.ru> wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> I'm betting he means being able to import a module in a way that it's names
>>> (entities) are available only as fully-qualified names, and so the base names
>>> are not "imported" to the importing module namespace/scope. It's the FQN
>>> import.
>>>
>>> Andrei, (and others) if you want to check out some previous discussion on
>>> this matter:  http://www.digitalmars.com/d/archives/digitalmars/D/28423.html
>>
>> Yes, you're right.
> 
>> But anyway, as far as I can see Walter's opinion is unknown.
>>  Is he satisfied with the present situation?
> 
> I believe so.
> 
> The curent situation is a syntax shortcut. No one is prevented from using FQN syntax, and in fact I try to use that form in my code, with the main exception being 'writefln' of course ;-)
> 
> The benefit I can see from the shortcut form is that one can change modules without having to change references to members in that module, whereas with FQN usage one has to do a global find/replace over all your source code.
> 
> The cost of not using FQN though is it does not keep well over time in terms of reading the code and have an understanding of it. Plus you can get caught out sometimes when introducing another import that causes name clashes.
> 
> I'm not an advocate of either style of coding and I won't dictate to others either on this matter. I have a preference, as my fellow coders also have a preference, which may be different, and I'm okay with that.
> 
> Why do you think that FQN syntax is demonstrable better than the current shortcut syntax?
> 
> --Derek Parnell
> Melbourne, Australia

The thing I'd see useful here would be:

import fb : foo.bar;

Indicates all methods from module "foo.bar" are in local namespace "fb"

import $ : foo.bar;

Would be the same as

import foo.bar : foo.bar;

Regards,
Sjoerd

Sjoerd van Leent wrote:
>> The curent situation is a syntax shortcut. No one is prevented from using FQN syntax, and in fact I try to use that form in my code, with the main exception being 'writefln' of course ;-)
>>
>> The benefit I can see from the shortcut form is that one can change modules without having to change references to members in that module, whereas with FQN usage one has to do a global find/replace over all your source code.
>>
>> The cost of not using FQN though is it does not keep well over time in terms of reading the code and have an understanding of it. Plus you can get caught out sometimes when introducing another import that causes name clashes.
>>
>> I'm not an advocate of either style of coding and I won't dictate to others either on this matter. I have a preference, as my fellow coders also have a preference, which may be different, and I'm okay with that.
>>
>> Why do you think that FQN syntax is demonstrable better than the current shortcut syntax?
>>
>> --Derek Parnell
>> Melbourne, Australia
> 
> 
> The thing I'd see useful here would be:
> 
> import fb : foo.bar;
> 
> Indicates all methods from module "foo.bar" are in local namespace "fb"
> 
> import $ : foo.bar;
> 
> Would be the same as
> 
> import foo.bar : foo.bar;
> 
> Regards,
> Sjoerd


or perhaps import x.y.z as foo;

Where the "as <name>" is optional

kris wrote:
> or perhaps import x.y.z as foo;
> 
> Where the "as <name>" is optional
This is a very clean syntax, reminds me of ml. I hope Walter sees and implements this.

Sjoerd van Leent wrote:
> The thing I'd see useful here would be:
> 
> import fb : foo.bar;
> 
> Indicates all methods from module "foo.bar" are in local namespace "fb"
> 
> import $ : foo.bar;
> 
> Would be the same as
> 
> import foo.bar : foo.bar;
> 
> Regards,
> Sjoerd

It is worth reviewing the Python syntax for imports here, I think. Python uses the FQN import by default, but supports importing unqualified names as well.

So, given a module foo.bar with a function inside named baz, we can say:

>>> import foo.bar
>>> foo.bar.baz()

To import a module and make it available as an alias, you'd say:

>>> import foo.bar as fb
>>> fb.baz()

To only import a specific name from a module, you'd say:

>>> from foo.bar import baz
>>> baz()

(This is a feature I'd love to see in D, actually. The ability to only import a specific name from a module would be great.)

To import a specific name under an alias, you'd say:

>>> from foo.bar import baz as b
>>> b()      # calls foo.bar.baz()

If you want to import all names from a module into the current namespace (the D style of import), you can say:

>>> from foo.bar import *
>>> baz()

It's worth noting that, for all of these except the last form, all names that are imported are explicitly mentioned in the import statement. I think this is a highly desirable state of affairs. It is for this reason that frivolous use of the "from x import *" form is somewhat frowned upon. It is quite useful for importing some large libraries, however (certain GUI libraries, for instance), so there are certainly valid uses for it.

The visibility of imported names, then, follows naturally:

# blah.py
from foo.bar import baz
# EOF

>>> import blah
>>> blah.baz()   # calls foo.bar.baz
>>> from blah import baz
>>> baz()        # calls foo.bar.baz

-Kirk McDonald

Kirk McDonald wrote:
> Sjoerd van Leent wrote:
> 
>> The thing I'd see useful here would be:
>>
>> import fb : foo.bar;
>>
>> Indicates all methods from module "foo.bar" are in local namespace "fb"
>>
>> import $ : foo.bar;
>>
>> Would be the same as
>>
>> import foo.bar : foo.bar;
>>
>> Regards,
>> Sjoerd
> 
> 
> It is worth reviewing the Python syntax for imports here, I think. Python uses the FQN import by default, but supports importing unqualified names as well.
> 

Some additional features of Python. :-)

> So, given a module foo.bar with a function inside named baz, we can say:
> 
>  >>> import foo.bar
>  >>> foo.bar.baz()
> 

Like D, you can say e.g.:
>>> import foo.bar, foo.baz, foo.boo

> To import a module and make it available as an alias, you'd say:
> 
>  >>> import foo.bar as fb
>  >>> fb.baz()
> 
> To only import a specific name from a module, you'd say:
> 
>  >>> from foo.bar import baz
>  >>> baz()
> 

You can also say:
>>> from foo.bar import baz, boo, blah

Which is quite useful if you just need a handful of names from a module.

> (This is a feature I'd love to see in D, actually. The ability to only import a specific name from a module would be great.)
> 
> To import a specific name under an alias, you'd say:
> 
>  >>> from foo.bar import baz as b
>  >>> b()      # calls foo.bar.baz()
> 

This can similiarly be expanded as:
>>> from foo.bar import baz as b, boo as o, blah as a

> If you want to import all names from a module into the current namespace (the D style of import), you can say:
> 
>  >>> from foo.bar import *
>  >>> baz()
> 
> It's worth noting that, for all of these except the last form, all names that are imported are explicitly mentioned in the import statement. I think this is a highly desirable state of affairs. It is for this reason that frivolous use of the "from x import *" form is somewhat frowned upon. It is quite useful for importing some large libraries, however (certain GUI libraries, for instance), so there are certainly valid uses for it.
> 
> The visibility of imported names, then, follows naturally:
> 
> # blah.py
> from foo.bar import baz
> # EOF
> 
>  >>> import blah
>  >>> blah.baz()   # calls foo.bar.baz
>  >>> from blah import baz
>  >>> baz()        # calls foo.bar.baz
> 
> -Kirk McDonald