module foo.bar.one;
module foo.bar.internals; // package-protected utilities
module foo.bar.subpkg.two;
module foo.bar.subpkg.internals; // package-protected utilities


Current situation: module 'one' cannot access the 'bar.subpkg' utilities, and module 'two' cannot access the 'bar' utilities.  This is needlessly limiting, forcing design choices that should not be dictated by the ability/inability to separate public and private API.  It also precludes many valid and good uses of nested package.d modules.

I really don't see any equally strong counter-argument.  But then, I've wanted this exact fix for literally years now.

It also is not limited to internal utility modules.  It can be useful for systems that select at compile time from one of a number of system-specific implementations of a given interface/api.  It can be useful for granting privileged access to certain api's and/or resources to specific module(s).  An example being: grant access to unsafe but versitile data manipulators solely to the subpackage containing the loaders.

Currently, there is no absolutely enforceable way of doing such things; so one ends up falling back on convention... and conventions, sadly, never hold in the real world for long.

On Wed, 20 Aug 2014 10:19:59 -0700
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> No need to demean the question. It is valid. -- Andrei
sorry, i don't mean to insult anyone, just trying to make people see analogies. hierarchies are everywhere, it's convient way to store alot of things. modules itself is a great example of hierarchies -- we can dump all source code in one file instead of using modules.

i.e. file system hierarchy is handy what there are many files. module hierarchy is handy when there are many modules in library. the ability to have fine-grained visibility control in module hierarchy is handy.

this was written numerous times in this thread, yet he continues to ask the same question again and again as if he just don't bother to read any answers. that's why i asked about subdirs.

On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
> On 8/19/2014 7:01 AM, Dicebot wrote:
> > Walter, now that release is out can you please state your
> opinion about
> > https://github.com/D-Programming-Language/dmd/pull/3651 ? It
> is blocking Phobos
> > module split and decoupling.
>
> I keep thinking there's gotta be a way to do this without language changes.

For what it's worth I don't care how things turn out w.r.t. syntax, language extension or convention but the problem must be solved.


The way I see the problem:

There must be nice and clean way to have internal stuff that is invisible for user. Preferably this stuff must not be monolithic and have form of package.

Example structure:
mod/package.d
mod/internal/bar.d
mod/...

I actually face it in Phobos right now, my blocked pull:
https://github.com/D-Programming-Language/phobos/pull/2412

Options:

1. Use current package attribute.
Disadvantages:
a) Must retain internals in the same package, user may still import them no problem at all. At least it does not do much harm as nothing is accessible.
b) Can't use std.mod.internal.bar 'package' stuff in std.mod (upper one). That makes it next to unusable. Basically it means we have to push internals up, instead of pushing them down.

2. Use separate public internal package.
Main disadvantage:
a) Now user may import and actually USE internal stuff.
b) Not only that but also internal methods of equally internal structs and classes leak out. In other words: a struct defined in internal module may never be exposed without some kind of wrapping. Ugly and unnecessary complication.


I'd rather have a language feature, but whatever you guys invent as 3rd option that doesn't suck will have my vote.


---
Dmitry Olshansky

All I want is that whatever decision Walter makes to happen sooner than in few years from now.

Dicebot:

> All I want is that whatever decision Walter makes to happen sooner than in few years from now.

There are other pending patches, like the support for the nice [$] syntax by Kenji.

"I keep thinking there's gotta be a way to do this without language changes." or "I keep thinking there must be a better way than [$]." are the kind of standard answers Walter gives when he doesn't have time to think about some design (because he has time he usually needs only hours or very few days to implement features, like when he made UDAs or C++ namespeces).

So I guess Walter is currently busy with something (like finishing the 2.066 release and its regressions, or developing Warp for Facebook, or something else), so you have to wait some time for him to come back to the language development side, to receive a good answer and a good solution.

Bye,
bearophile

On Fri, 22 Aug 2014 20:48:22 +0000
bearophile via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

or (smart plan!) just apply the necessary PRs, build dmd from sources and start using the features. if authors of popular libraries will do this, there will be no choice and maintainers will be forced to apply this patches. this is called 'driven by the community'. ;-)

ok-ok-ok, you got me, this was a silly joke! or maybe not?..

On Sat, 23 Aug 2014 04:50:36 +0300
ketmar via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

to be honest, i myself is a happy user of Kenji's $ patch and package(...) patch. yes, it costs some efforts to keep 'em up-to-date, but hey, i have no life anyway.

On Friday, 22 August 2014 at 15:06:14 UTC, Dmitry Olshansky wrote:
> Example structure:
> mod/package.d
> mod/internal/bar.d
> mod/...
>
> I actually face it in Phobos right now, my blocked pull:
> https://github.com/D-Programming-Language/phobos/pull/2412

I think, it should have structure

std.regex.package;
std.regex.backtracking;
std.regex.ir;

What is the reason to have regex stuff in a remote directory? That would make things hard to find and navigate.

On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote:
> On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote:
>> As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy.
>
> We _may_ split it into flat set files (solving only part of the problem) but it is desirable to have a deeper package hierarchy. Package hierarchy is not just an encapsulation tool, it is also a great way to simplify navigation and finding needed modules - something that Phobos is current terrible at exactly because of flat hierarchies.

What is difficult to find? With flat structure you have all files right before your eyes. If you need std.datetime.systime module, you open std/datetime/systime.d file - that's the reason of needlessly restricting code structure with modules as if one size fits all.

On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote:
> On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote:
>> As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy.
>
> We _may_ split it into flat set files (solving only part of the problem) but it is desirable to have a deeper package hierarchy. Package hierarchy is not just an encapsulation tool, it is also a great way to simplify navigation and finding needed modules - something that Phobos is current terrible at exactly because of flat hierarchies.

And with an excessively deep folder structure it will be much more tedious to walk the whole thing. It's deep nesting, which will make things hard to find.