On 2/6/13, Don <don@nospam.com> wrote:
> (b) The current flat structure of Phobos (every module in the
> root) does not scale to hundreds of modules.

I just want to add that we're still handicapped by D's access attributes preventing us from moving private functionality into a separate module.

On Thursday, February 07, 2013 23:56:30 Andrej Mitrovic wrote:
> On 2/6/13, Don <don@nospam.com> wrote:
> > (b) The current flat structure of Phobos (every module in the
> > root) does not scale to hundreds of modules.
> 
> I just want to add that we're still handicapped by D's access attributes preventing us from moving private functionality into a separate module.

And why is this a handicap? They're private, not part of the API, so they should totally irrelevant to how modules are laid out.

- Jonathan M Davis

On Thursday, 7 February 2013 at 22:56:39 UTC, Andrej Mitrovic wrote:
> On 2/6/13, Don <don@nospam.com> wrote:
>> (b) The current flat structure of Phobos (every module in the
>> root) does not scale to hundreds of modules.
>
> I just want to add that we're still handicapped by D's access
> attributes preventing us from moving private functionality into a
> separate module.

That is the whole point of private. If something is imported from elsewhere and used, by definition, it isn't private.

On 2/8/13, deadalnix <deadalnix@gmail.com> wrote:
> That is the whole point of private. If something is imported from elsewhere and used, by definition, it isn't private.
On 2/8/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> And why is this a handicap? They're private, not part of the API, so they should totally irrelevant to how modules are laid out.

Have you ever tried to used a project layout where you implement private (e.g. OS-specific) functionality into their own subpackages, which should only be accessible to the library and not the user? Because this is impossible to do right now. IOW if you have:

./std/algorithm.d
./std/range.d

Say that both modules require some private internal template called "MagicTemplate".

Personally I find it ideal to use internal packages for this, e.g.:

./std/algorithm.d
./std/range.d
./std/internal/templates.d  -- contains MagicTemplate, imported by
algorithm and range

But this forces you to make MagicTemplate public, as package access won't work in this case.

Maybe "handicapped" was the wrong word for this. You could put the template in algorithm.d or range.d and have one module import the other (which has its own problems, e.g. with module constructors), or you could put the internal.d module in the std package and set package access to MagicTemplate:

./std/algorithm.d
./std/range.d
./std/internal.d  -- contains MagicTemplate with package access

But I prefer to have internal modules in subpackages, which is impossible to do right now in D due to how access specifiers work (i.e. everything ends up being public). Anyway it's not a blocker but it's worth thinking about.

On Friday, 8 February 2013 at 13:14:09 UTC, Andrej Mitrovic wrote:
> ...

As far as I can see it, this will be automatically settled once package import DIP is done. Because then you can have hierarchy like this:

std/algorithm/_.d
std/algorithm/implementation.d

..and use "package" protection attribute.

On Friday, 8 February 2013 at 13:14:09 UTC, Andrej Mitrovic wrote:
> But I prefer to have internal modules in subpackages, which is
> impossible to do right now in D due to how access specifiers work
> (i.e. everything ends up being public). Anyway it's not a blocker but
> it's worth thinking about.

Considering imports can be private, I don't see it as a big problem.

Surely the user won't have any expectations if he chooses to explicitly import a module that is clearly labeled internal.