Small troubles with "private"

[Regan Heath]

On Tue, 05 Nov 2013 16:00:41 -0000, bearophile <bearophileHUGS at lycos.com>  
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.

I think a compiler flag is the best option.  The flag would cause warnings  
to appear for each "violation" of strict privacy between classes in the  
same module.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/