Subject: Re: [std-proposals] Friend namespace
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-12-06 08:29:50
On Sun, Dec 6, 2020 at 4:24 AM Peter C++ via Std-Proposals <
> To start with, you should not test private stuff. It is private, so it
> might change. Binding tests to the private parts makes them harder to
> change, because of the tests, that should make software easier to refactor
> and change.
I agree with Peter here.
"Refactoring for testability" is definitely a thing. This generally
involves at least two parts, and maybe more:
(1) Make sure all your *dependencies* are *injected*
(2) Make sure all your *functionality* is *exposed*
#2 doesn't have any catchy phrase the way #1 has "dependency injection."
But generally, if your complaint is "Class Foo's `x` method is private, but
I want to test it!" then the obvious fix is to make Foo's `x` method
public. If your complaint is "My unit-testing framework requires `Foo` to
have an operator<<!" then the obvious fix is to give `Foo` an operator<<.
And so on.
Also, notice that if you friend a whole namespace... Namespaces, unlike
classes, are *open*. Physically speaking, anybody in any .cpp file can add
a new member to any namespace. So by friending a namespace you'd be saying
"I don't really care *who* can access my private stuff."
Technically this is already true of `private`, because of this hack I
blogged three days ago
but I consider that more of a loophole that might one day get *fixed*, if
anyone can figure out how. I definitely wouldn't want to see WG21 put any
effort toward *increasing* the visibility of private members.
STD-PROPOSALS list run by firstname.lastname@example.org
Standard Proposals Archives on Google Groups