Fix #2529: explicit protection package #3651
Dicebot via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Wed Aug 20 10:11:45 PDT 2014
On Wednesday, 20 August 2014 at 15:13:06 UTC, Kagamin wrote:
> 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.
This is just your design preference and hardly a good "one size
fits them all" decision. I also don't speak about inheritance but
about composition - customization may be implemented via unsafe
field exposure and unsuitable for general public usage but useful
for simplifying internal implementation maintenance. We should
not force users into single good package structure based on
certain design beliefs.
>> 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.
Same here. As library size grows you completely lose the
distinction between "public" and "internal", certain parts of the
library may become hidden from other parts and public but
available for others. It is pretty much a necessity to keep up
with maintenance when there is a large team working on it
simultaneously. Right now people mostly rely on convention, I
have seem quite some comments like "should have been private but
needs to be accessed from module X, don't ever touch it"
(public-but-undocumented functions of Phobos sometimes fall into
the same category).
Telling people that they design applications in a wrong way and
need to change their habits is a good approach to alienate them
against the language.
More information about the Digitalmars-d-announce
mailing list