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