On Tuesday, 5 November 2013 at 16:00:43 UTC, bearophile wrote:
1) I usually write more than one class or struct inside each D
module, unlike in Java. But sometimes when I move that class or
struct elsewhere (during refactoring, or in other situations) I
get access errors to private fields. Those errors were already
in my code, but I didn't see them because "private" in D means
module-private.
2) My unittests are useful to catch bugs when I run them at
run-time, but they are also use to exercise code, this means to
actually use it, and catch some bugs statically (instantiating
templates, etc). But unfortunately such unittests can't catch
protection bugs because most of my unittests are inside the
same module, so "private" gets ignored.
3) A third problem with module-private is that newbies coming
from Python, C, and other languages that don't have
private/protected attributes and write little experimental D
programs, have less chances to _learn_ the true semantics of
the privacy attributes until they start to spread their classes
in different modules.
How to solve such little troubles? A possible idea is to add to
D another attribute, a kind of "private private" that is
enforced inside the same module. It could be named "super
private" because D has the "super" keyword :-) But this idea
doesn't solve all the problems, because sometimes you don't
want to use a super private attribute.
Bye,
bearophile
IMHO private should mean private as enforced by other languages
and use another keyword for module level privacy. 'internal'
springs to mind.
