On 11/05/2013 05:00 PM, 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
How about just adding full granularity?
By condition:
@visibleIf!true // public
@visibleIf!(isSubtypeOf!(typeof(this))) // protected
By explicit enumeration:
@visible!(getModule!(typeof(this))) // private
@visible!(typeof(this), T) // visible to type 'T'
@visible!(typeof(this)) // 'super private'
@visible!foo // only (member) function 'foo' can access it
@visible!() // nobody can access it
