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.

Reply via email to