Why do private member variables behaved like protected in the same module when creating deriving class?

Stanislav Blinov stanislav.blinov at gmail.com
Fri Nov 2 12:53:44 UTC 2018


On Friday, 2 November 2018 at 11:43:13 UTC, Atila Neves wrote:
> On Thursday, 1 November 2018 at 17:59:35 UTC, Steven 
> Schveighoffer wrote:

>> So... don't test private functions?
>
> Precisely.
>
> Caveat: test them if you *really* want to, but be prepared to 
> delete the tests with extreme prejudice.
>
> I never do, implementation details are just that.

Sometimes you need to, even if you don't want to. Say you're 
implementing a container, for simplicity let's say an Array!T 
(akin to Vector from your automem library). Because it's D, the 
author needs to be aware of GC implications. Namely, when 
removing elements from the array, or reserving additional 
storage, and `T` may have indirections, the Array should wipe 
unused storage (or appropriate bits) to eliminate false pointers. 
This isn't a part of public interface at all, but still something 
that should be tested against.


More information about the Digitalmars-d mailing list