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.

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.

Any specific ideas? I can't imagine any clean solution - and proposed language extensions fits naturally into existing system without introducing any new concepts. It is also somewhat frequently asked about in NG.

On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
> 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.
>
> Any specific ideas? I can't imagine any clean solution - and proposed language extensions fits naturally into existing system without introducing any new concepts. It is also somewhat frequently asked about in NG.

Yeah, I don't see how this could be done without a language change. Currently, modules in sub-packages are treated no differently from modules in completely different packages, so anything you did to give access to a module in a super-package to one in a sub-package would give access to any module.

- Jonathan M Davis

On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
> 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.
>
> Any specific ideas? I can't imagine any clean solution - and proposed language extensions fits naturally into existing system without introducing any new concepts. It is also somewhat frequently asked about in NG.

To put it differently - this issue is a very real blocker for some of planned Phobos changes (pretty much anything that is going to use package.d) and it has been hanging around for a long time. If you are going to propose alternative solution I'd be very glad to see it sooner than later as everyone else who has commented on that topic seems to be satisfied with the proposal.

On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
> Any specific ideas? I can't imagine any clean solution - and proposed language extensions fits naturally into existing system without introducing any new concepts. It is also somewhat frequently asked about in NG.

---
module std.internal.mod1;
package(std) void foo() {}

module std.mod2;
import std.internal.mod2;
void bar() { foo(); }
---

Isn't it equivalent to
---
module std.internal_mod1;
package void foo() {}

module std.mod2;
import std.internal_mod1;
void bar() { foo(); }
---

On Wed, 20 Aug 2014 07:25:43 +0000
Kagamin via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

but it requires to dump all 'subpackages' into one flat directory and with ugly names.

proposed extension will not break any existing code, yet will allow much nicer hierarchy.

On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via Digitalmars-d-announce wrote:
> but it requires to dump all 'subpackages' into one flat directory and
> with ugly names.

Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that?

On Wed, 20 Aug 2014 09:26:36 +0000
Kagamin via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that?
imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them
not single module, but package itself. so we have module
mybiglib.other.thingy which wants to use functions from
module mybiglib.internal.wisdom, which is part of mybiglib.internal
package.

On Wednesday, 20 August 2014 at 09:26:37 UTC, Kagamin wrote:
> On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via Digitalmars-d-announce wrote:
>> but it requires to dump all 'subpackages' into one flat directory and
>> with ugly names.
>
> Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that?

Your proposal makes such module layout illegal:

std.package1.module1
std.package1.module2
std.package1.subpackage.module1
std.package1.subpackage.module2

(can't have symbols in subpackage that are also available to package1 but not whole std / public, must have `subpackage_module1` instead, `package_1_subpackage_module1` if it must be available for whole std)

It severely limits expressive power of package system for code organization and encourages flat hierarchies with minimal nesting. It also looks ugly - anyone seeing module name with package name mangled in it will feel that there is something wrong with the language if it needs to resort to such hacks.

On Wednesday, 20 August 2014 at 13:05:54 UTC, Dicebot wrote:
> Your proposal makes such module layout illegal:
>
> std.package1.module1
> std.package1.module2
> std.package1.subpackage.module1
> std.package1.subpackage.module2
>
> (can't have symbols in subpackage that are also available to package1 but not whole std / public, must have `subpackage_module1` instead, `package_1_subpackage_module1` if it must be available for whole std)

If some utility is internal to std.package1 an used in the entire std.package1, shouldn't it sit in std.package1? Why push it to subpackage?

std.package1.module1
std.package1.module2
std.package1.internal <- package1's internals go here
std.package1.subpackage.module1
std.package1.subpackage.module2