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