Modules vs Packages

[Bill Baxter]

Kirk McDonald wrote:
> 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).

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