Modules vs Packages

[Kirk McDonald]

Bill Baxter wrote:
> Jarrett Billingsley wrote:
> 
>> "Giuseppe Bilotta" <giuseppe.bilotta at gmail.com> wrote in message 
>> news:fbtpp1$2k8t$1 at 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