https://github.com/D-Programming-Language/dmd/pull/2139

Andrei

Andrei Alexandrescu:

> https://github.com/D-Programming-Language/dmd/pull/2139

Probably you already know the following things because they see, similar solutions.

Python uses "__init__.py" instead of "package.d", it can also be empty:
http://docs.python.org/2/tutorial/modules.html

__init__.py can also execute initialization code for the package, like static this() in D.

Inside __init__.py you can also define a "__all__" variable where you list all the modules imported when "from package import *" is used.

>If __all__ is not defined, the statement from sound.effects import * does not import all submodules from the package sound.effects into the current namespace; it only ensures that the package sound.effects has been imported (possibly running any initialization code in __init__.py) and then imports whatever names are defined in the package. This includes any names defined (and submodules explicitly loaded) by __init__.py. It also includes any submodules of the package that were explicitly loaded by previous import statements.<

Bye,
bearophile

On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/dmd/pull/2139


Well, I am destroyed. I need to do some more engineering. The problem is that packages and modules have become conflated with this change.

Am Wed, 05 Jun 2013 18:31:22 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> https://github.com/D-Programming-Language/dmd/pull/2139
> 
> Andrei

To those who don't want to see a < 1000 lines module: Please
consider that as soon as we'd merge multiple compression
algorithms into one file for the sake of making the module
"large enough", it will turn back on us when we decide to
implement any larger number of those:
http://en.wikipedia.org/wiki/Category:Lossless_compression_algorithms

I see one down side though: Some algorithms are alterations of others and could reuse code. For the sake of speaking module names I'd still split the compression algorithms into multiple modules and probably let one import the other.

-- 
Marco

On Thursday, June 06, 2013 04:10:26 Marco Leise wrote:
> Am Wed, 05 Jun 2013 18:31:22 -0400
> 
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> > https://github.com/D-Programming-Language/dmd/pull/2139
> > 
> > Andrei
> 
> To those who don't want to see a < 1000 lines module: Please
> consider that as soon as we'd merge multiple compression
> algorithms into one file for the sake of making the module
> "large enough", it will turn back on us when we decide to
> implement any larger number of those:
> http://en.wikipedia.org/wiki/Category:Lossless_compression_algorithms
> 
> I see one down side though: Some algorithms are alterations of others and could reuse code. For the sake of speaking module names I'd still split the compression algorithms into multiple modules and probably let one import the other.

If each of the compression algorithms is in its own module which is in the same package as other compression modules, then they can use package access to share stuff that would be specific to them but not belong in Phobos in general. But I believe that package level access only works on the same level, so you couldn't have separate modules for compressing and decompressing as was being suggested. It would need to be more like

std.compress.zlib;
std.compress.lzw;

At that point, it would be trivial to have a common module of some kind with shared functionality which has package access level.

- Jonathan M Davis

On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:

> But I believe that package level access only works on the same level, so you couldn't have separate modules for compressing and decompressing as was being suggested. It would need to be more like
>
> std.compress.zlib;
> std.compress.lzw;
>
> At that point, it would be trivial to have a common module of some kind with
> shared functionality which has package access level.
>
> - Jonathan M Davis

+1

That seems to be the right level of granularity.

On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:

> But I believe that package level access only works on the same level, so you
> couldn't have separate modules for compressing and decompressing as was being
> suggested.

'package' should be fixed so that 'package' declarations are accessible within nested packages.

On 6/5/2013 5:13 PM, Walter Bright wrote:
> On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
>> https://github.com/D-Programming-Language/dmd/pull/2139
>
>
> Well, I am destroyed. I need to do some more engineering. The problem is that
> packages and modules have become conflated with this change.

Fixed and reopened.

On Thursday, June 06, 2013 08:09:38 Max Samukha wrote:
> On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
> > But I believe that package level access only works on the same
> > level, so you
> > couldn't have separate modules for compressing and
> > decompressing as was being
> > suggested.
> 
> 'package' should be fixed so that 'package' declarations are accessible within nested packages.

Well, it _is_ debatable as to whether that's desirable or not. With the current behavior, you can have a package which shares stuff within itself but not with its sub-packages, but there's no way to share with the sub-packages without making the symbols public; whereas if sub-packages have access to their parent packages' package functions, then packages _can_ share with their sub-packages, but they can't restrict anything to just the package. Both ways have their pros and cons. I don't know which is ultimately better.

- Jonathan M Davis

Am Wed, 05 Jun 2013 22:35:59 -0400
schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:

> std.compress.zlib;
> std.compress.lzw;
> 
> At that point, it would be trivial to have a common module of some kind with shared functionality which has package access level.
> 
> - Jonathan M Davis

+1

If package is ambiguous, maybe it needs to be split in two or take a parameter package(std.algorithm) or something like that to serve both use cases.

-- 
Marco