www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Modules vs Packages

reply Giuseppe Bilotta <giuseppe.bilotta gmail.com> writes:
Hello all,

as mentioned before, I'm a beginner at D but I just came across
another interesting limitation. I'm building this reliable
computing package, which would be composed by a number of modules
such as relcomp.ia for interval analysis and relcomp.aa for affine
arithmetic etc. Of course, in some cases it would make sense to
import all the package modules at once, so I my first thought was
to create a relcomp.d module which public-imported relcomp.ia,
relcomp.aa and whatever else.

This failed with the D frontend complaining that the relcomp
package and module had the same name. I must admit I was surprised
by this result. I'm probably misunderstanding the module
mechanism, but I see no reason why we couldn't have

package.d
package/module1.d
package/module2.d

etc, and be able to import package. The same could go on for
abitrary depth:

package.d
package/subpack.d
package/subpack/mod.d

to be imported as

import package;

or

import package.subpack

or

import package.subpack.mod

Why not?

-- 
Giuseppe "Oblomov" Bilotta
Sep 08 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Giuseppe Bilotta" <giuseppe.bilotta gmail.com> wrote in message 
news:fbtpp1$2k8t$1 digitalmars.com...

 I see no reason why we couldn't have

 package.d
 package/module1.d
 package/module2.d

This has been brought up so many times.. I think Walter needs to put an explanation of this on the modules page. I don't see the reason for it either. I think other people have explained it as something along the lines of "packages aren't the same as modules, so you can't have one name map to two things". I don't buy that. I don't see how packages are any different from modules. They're both just namespaces. That's how they work in my scripting language: packages == modules, and you can have packages and modules with the same name. Until (if) this changes, the most common way to do what you want to do in D is to have a "relcomp.all" module which imports everything else.
Sep 08 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Giuseppe Bilotta" <giuseppe.bilotta gmail.com> wrote in message 
 news:fbtpp1$2k8t$1 digitalmars.com...
 
 I see no reason why we couldn't have

 package.d
 package/module1.d
 package/module2.d

This has been brought up so many times.. I think Walter needs to put an explanation of this on the modules page. I don't see the reason for it either. I think other people have explained it as something along the lines of "packages aren't the same as modules, so you can't have one name map to two things". I don't buy that. I don't see how packages are any different from modules. They're both just namespaces. That's how they work in my scripting language: packages == modules, and you can have packages and modules with the same name. Until (if) this changes, the most common way to do what you want to do in D is to have a "relcomp.all" module which imports everything else.

And I recommend .api instead of .all if you don't actually import /all/ the modules. Or even if you do. Or I suppose you could have both - .api being lean and mean API, and .all being the moral equivalent of #include <windows.h>. (This .api convention comes from python, btw. see e.g. http://neuroimaging.scipy.org/neuroimaging/ni/ticket/86) --bb
Sep 08 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 Jarrett Billingsley wrote:
 
 "Giuseppe Bilotta" <giuseppe.bilotta gmail.com> wrote in message 
 news:fbtpp1$2k8t$1 digitalmars.com...

 I see no reason why we couldn't have

 package.d
 package/module1.d
 package/module2.d

This has been brought up so many times.. I think Walter needs to put an explanation of this on the modules page. I don't see the reason for it either. I think other people have explained it as something along the lines of "packages aren't the same as modules, so you can't have one name map to two things". I don't buy that. I don't see how packages are any different from modules. They're both just namespaces. That's how they work in my scripting language: packages == modules, and you can have packages and modules with the same name. Until (if) this changes, the most common way to do what you want to do in D is to have a "relcomp.all" module which imports everything else.

And I recommend .api instead of .all if you don't actually import /all/ the modules. Or even if you do. Or I suppose you could have both - .api being lean and mean API, and .all being the moral equivalent of #include <windows.h>. (This .api convention comes from python, btw. see e.g. http://neuroimaging.scipy.org/neuroimaging/ni/ticket/86) --bb

Python also has a special module name "__init__", which acts as a central import-point for a package: package/ __init__.py foo.py bar.py If you say "import package", you're actually importing package/__init__.py. (In fact, you're required to have at least an empty __init__.py module. It's presence is what makes a directory be treated as a package. D does not need this behavior, however.) Having a specially-named module inside the directory is preferable to having a same-named module at the same level as the package (which Python doesn't allow, either), since then the package lives entirely inside its own directory. (Which is the entire point of having a package, as I see it.) The reasons given for the api.py convention in the link above do not generally apply to D. Something equivalent to __init__.py would be sufficient. I suggest "this.d". Being a keyword, 'this' cannot be used as a regular module name. It also evokes existing D syntax (and, indeed, is like Python using __init__, which is the name Python uses for class constructors). It's worth pointing out (again) that D's import, module, and package semantics are a lot like Python's. It has already shamelessly stolen selective, static, and renaming imports from Python, and so it should go whole hog and get this in there, as well. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 08 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 Jarrett Billingsley wrote:

 "Giuseppe Bilotta" <giuseppe.bilotta gmail.com> wrote in message 
 news:fbtpp1$2k8t$1 digitalmars.com...

 I see no reason why we couldn't have

 package.d
 package/module1.d
 package/module2.d

This has been brought up so many times.. I think Walter needs to put an explanation of this on the modules page. I don't see the reason for it either. I think other people have explained it as something along the lines of "packages aren't the same as modules, so you can't have one name map to two things". I don't buy that. I don't see how packages are any different from modules. They're both just namespaces. That's how they work in my scripting language: packages == modules, and you can have packages and modules with the same name. Until (if) this changes, the most common way to do what you want to do in D is to have a "relcomp.all" module which imports everything else.

And I recommend .api instead of .all if you don't actually import /all/ the modules. Or even if you do. Or I suppose you could have both - .api being lean and mean API, and .all being the moral equivalent of #include <windows.h>. (This .api convention comes from python, btw. see e.g. http://neuroimaging.scipy.org/neuroimaging/ni/ticket/86) --bb

Python also has a special module name "__init__", which acts as a central import-point for a package: package/ __init__.py foo.py bar.py If you say "import package", you're actually importing package/__init__.py. (In fact, you're required to have at least an empty __init__.py module. It's presence is what makes a directory be treated as a package. D does not need this behavior, however.) Having a specially-named module inside the directory is preferable to having a same-named module at the same level as the package (which Python doesn't allow, either), since then the package lives entirely inside its own directory. (Which is the entire point of having a package, as I see it.) The reasons given for the api.py convention in the link above do not generally apply to D. Something equivalent to __init__.py would be sufficient. I suggest "this.d". Being a keyword, 'this' cannot be used as a regular module name. It also evokes existing D syntax (and, indeed, is like Python using __init__, which is the name Python uses for class constructors).

Yeh, but D doesn't /have/ such a thing right now. Naming modules things like 'all' or 'api' is our only option right now.
 It's worth pointing out (again) that D's import, module, and package
 semantics are a lot like Python's. It has already shamelessly stolen
 selective, static, and renaming imports from Python, and so it should go
 whole hog and get this in there, as well.

Agreed. And if it does, I think calling the special file "this.d" would be very D-ish. --bb
Sep 08 2007
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Kirk McDonald wrote:
 [snip]

 The reasons given for the api.py convention in the link above do not
 generally apply to D. Something equivalent to __init__.py would be
 sufficient. I suggest "this.d". Being a keyword, 'this' cannot be used
 as a regular module name. It also evokes existing D syntax (and, indeed,
 is like Python using __init__, which is the name Python uses for class
 constructors).

Oh, I *like* that solution. I don't suppose it's a coincidence that "this" in Python is "__init__"? :P
 It's worth pointing out (again) that D's import, module, and package
 semantics are a lot like Python's. It has already shamelessly stolen
 selective, static, and renaming imports from Python, and so it should go
 whole hog and get this in there, as well.

While we're at it, maybe we could get relative imports, too... :) -- Daniel
Sep 08 2007
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Jarrett Billingsley wrote:
 "Giuseppe Bilotta" <giuseppe.bilotta gmail.com> wrote in message 
 news:fbtpp1$2k8t$1 digitalmars.com...
 
 I see no reason why we couldn't have

 package.d
 package/module1.d
 package/module2.d

This has been brought up so many times.. I think Walter needs to put an explanation of this on the modules page. I don't see the reason for it either.

I think it was disallowed because package.d could contain some symbol with the same name as another module in the package. For example: // package.d struct a {}; // package/a.d ... // main.d import package.a; In this case it might be unclear whether the import refers to the struct in package.d or the module package.a. On the other hand, Kirk McDonald's suggestion to add a "this.d" module is very interesting. This should probably discussed further.
Sep 08 2007
parent Giuseppe Bilotta <giuseppe.bilotta gmail.com> writes:
On Sunday 9 September 2007 03:17, Julio C├ęsar Carrascal Urquijo wrote:

 I think it was disallowed because package.d could contain some symbol 
 with the same name as another module in the package. For example:

[snip]
 In this case it might be unclear whether the import refers to the struct 
 in package.d or the module package.a.

And in this case the compiler would complain loudly and refuse to continue. But doing a preemptive exception isn't that good an idea.
 On the other hand, Kirk McDonald's suggestion to add a "this.d" module 
 is very interesting. This should probably discussed further.

I like the this.d idea too. -- Giuseppe "Oblomov" Bilotta
Sep 09 2007