On Saturday, 23 August 2014 at 11:08:31 UTC, Kagamin wrote:
On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky
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.
That does contradict your statement that any stuff used in parent
packages must go to up the hierarchy which is exactly grouping by
I can probably give a more practical example I have just recently
encountered when re-designing one of our internal library
packages. It was a "serialization" package and sub-packages
defined different (de)serialization models, some of those
defining special wrapper types for resulting data that enforce
certain semantics specific to that serialization model via the
type system. It is not surprising that most internal details of
such wrappers were kept package protected as exposing those to
user could have easily violated all assumptions (but was needed
to implement (de)serialization efficiently).
It has become more complicated when "meta-serializers" have been
added to parent package - templated stuff that took any of
sub-package implementations and added some functionality (like
versioning support) on top. Being generic thing it reside in
higher level "serialization" package but to be implemented
efficiently it needs access to those internal wrapper fields.
Moving wrapper modules to parent package is not an option here
because those are closely related to specific serialization
model. Exposing stuff as public is not an option because anyone
not deeply familiar with package implementation can easily break
all type system guarantees that way. Moving "meta-serializers" to
sub-packages is quite a code duplication.
Right now I keep that stuff public and say in docs "please don't
use this" which is hardly a good solution.