On Saturday, 23 August 2014 at 11:08:31 UTC, Kagamin wrote:
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.

That does contradict your statement that any stuff used in parent packages must go to up the hierarchy which is exactly grouping by access :)

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.

Reply via email to