Fix #2529: explicit protection package #3651
Kagamin via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Wed Aug 20 08:13:05 PDT 2014
On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote:
> It may semantically belong to subpackage but still needs to be
> available to package1, something not uncommon in templated code
> (subpackage is generic implementation, package1 is
> specialization that still needs access to non-public functions).
If generic implementation is designed to be customized, it
probably means, it should be widely available for customization,
like xml document and base64 encoder. Also it's probably a
logical error if base type is less visible than the derived type.
> What you propose is effectively prohibiting to use packages to
> organize your code and requiring to design your module
> hierarchy based on desired protection relations, not other way
> around. I think it is conceptually wrong approach and
> unnecessarily restrictive compared to overall D design
> principles (no single "true" way of doing things)
It's ok for packages to exchange public interface, but internals?
If a subpackage has internals, they are for its usage, and
consumable functionality should be provided through public
interface.
More information about the Digitalmars-d-announce
mailing list