Expanding Phobos from a flat hierachy

Andrej Mitrovic andrej.mitrovich at gmail.com
Fri Feb 8 05:13:57 PST 2013


On 2/8/13, deadalnix <deadalnix at 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 at 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.


More information about the Digitalmars-d mailing list