On Wednesday, 20 August 2014 at 20:39:06 UTC, Chris Nicholson-Sauls wrote:
> module foo.bar.one;
> module foo.bar.internals; // package-protected utilities
> module foo.bar.subpkg.two;
> module foo.bar.subpkg.internals; // package-protected utilities
>
>
> and module 'two' cannot access the 'bar' utilities.

Really? Looks like a bug. You'd better check if it's intended to work that way.

> 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.

If some thing is used in entire foo.bar package, then it's foo.bar's internal, not foo.bar.subpkg's internal. I think, it's natural when the wider the thing is used, the higher in hierarchy it sits.

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

I don't really see, what it blocks.

> 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.

If those manipulators are used solely in loaders subpackage, they should belong to that package. Though I don't really see a problem here: there was an implementation of xml document, which allowed unsafe (but fast) specialization, which was believed to be useful for public usage. It fits well into D philosophy that safe things should be available by default and unsafe/fast things should be possible.

23-Aug-2014 12:57, Kagamin пишет:
> 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.

Yes, that was my initial pull. The stuff inside was marked as `package`, as only package.d currently has the same public API.

Then Dicebot suggested that since all modules are for the moment internal they have to be moved somewhere until public API is fleshed out (as it may change module name etc.).

2 options that both do NOT currently work:
std.regex.internal
std.internal.regex

-- 
Dmitry Olshansky

On Wednesday, 20 August 2014 at 14:44:21 UTC, Rory McGuire via Digitalmars-d-announce wrote:
> On Wed, Aug 20, 2014 at 4:33 PM, Kagamin via Digitalmars-d-announce <
> digitalmars-d-announce@puremagic.com> wrote:
>
>> Do we need a hierarchy of internals, is the problem this big? Why
>> mybiglib.wisdom is not good?
>>
>
> It gets really unwieldy when you want to put a whole bunch of things into
> one project and give control of different packages to different teams. Yes
> you could use multiple libraries in a lot of cases but if you're wanting it
> in a single setup / package (like phobos), especially one that is internal
> to another package you need sub-packages.

Yes, public interfaces of packages can form a hierarchy (which still shouldn't be more complex than necessary), but internals?

> Examples that would use this are:
> - kitchen sink libraries like phobos

I proposed an example of datetime module, that I don't see a problem with internals there. Can you point to an exact line in source, which suffers from this?

On 2014-08-23 11:12, Kagamin wrote:

> If some thing is used in entire foo.bar package, then it's foo.bar's
> internal, not foo.bar.subpkg's internal. I think, it's natural when the
> wider the thing is used, the higher in hierarchy it sits.

A symbol declared "package" can only be accessed within its own package. It cannot be accessed from sub packages or super packages.

-- 
/Jacob Carlborg

On Saturday, 23 August 2014 at 09:14:13 UTC, Dmitry Olshansky wrote:
> Yes, that was my initial pull. The stuff inside was marked as `package`, as only package.d currently has the same public API.
>
> Then Dicebot suggested that since all modules are for the moment internal they have to be moved somewhere until public API is fleshed out (as it may change module name etc.).
>
> 2 options that both do NOT currently work:
> std.regex.internal
> std.internal.regex

If the user relies that a symbol is found in std.internal.regex.backtracking, moving it will break the code too. So what's the difference?

On Saturday, 23 August 2014 at 09:24:04 UTC, Jacob Carlborg wrote:
> A symbol declared "package" can only be accessed within its own package. It cannot be accessed from sub packages or super packages.

I didn't know about that. Should it really work that way?

23-Aug-2014 13:33, Kagamin пишет:
> On Saturday, 23 August 2014 at 09:14:13 UTC, Dmitry Olshansky wrote:
>> Yes, that was my initial pull. The stuff inside was marked as
>> `package`, as only package.d currently has the same public API.
>>
>> Then Dicebot suggested that since all modules are for the moment
>> internal they have to be moved somewhere until public API is fleshed
>> out (as it may change module name etc.).
>>
>> 2 options that both do NOT currently work:
>> std.regex.internal
>> std.internal.regex
>
> If the user relies that a symbol is found in
> std.internal.regex.backtracking, moving it will break the code too. So
> what's the difference?

I don't see the difference. In any case user should see public aliases and never know where they lead to. Dicebot - any objections?

However since my pull hang there for months, I decide to appease puristic requests and move things to internals, only to find out that it doesn't work.

For what its worth I'd _prefer_ std.regex.internal as in my opinion internals got to be well contained. But as discussed, `package` doesn't work this way.


-- 
Dmitry Olshansky

On 2014-08-23 11:35, Kagamin wrote:

> I didn't know about that. Should it really work that way?

That's what we're trying to fix with this change.

-- 
/Jacob Carlborg

On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky wrote:
> For what its worth I'd _prefer_ std.regex.internal as in my opinion internals got to be well contained. But as discussed, `package` doesn't work this way.

It can be a philosophical matter, but in my experience grouping by functionality is genuine, and access is an afterthought, so grouping by access doesn't work in the long term, as code naturally (spontaneously) groups by functionality. The reason is when you maintain code, you traverse it according to functionality, because you work with implementation, and protection is interface, so protection is ignored. If you add a public functionality to internal module (ranges often end up like that), you can either just qualify it with public access, as it's done in normal modules, or refactor and move it to public module, so you end up with logically grouped functionality separated between two or more modules, which try to enforce grouping by access, while in normal modules you have logically grouped functionality in the same module even if they have different access. Also you can end up with public functionality in internal module, if the member proved to be stable, robust and use case for it arises.

On Saturday, 23 August 2014 at 11:04:35 UTC, Jacob Carlborg wrote:
> That's what we're trying to fix with this change.

The proposal is to make internals visible to super packages, I only wonder whether internals visible to some package should be hidden from its subpackages.