Le 2021-02-23 11:44, Niall Douglas via Boost a écrit :
On 23/02/2021 07:49, Krzysztof Jusiak wrote:
With DI that can be already achieved with constructor/named template deduction.
Let's try it then, shall we?
If you combined what you described with the ability for a runtime parsed config file to select which Allocator to inject (e.g. performance/debug/leakcheck), I'd personally find that motivating.
I think your introduction and tutorial need to be convincing people based on examples like that, as well. I think you need three convincing examples, each very different from the other, to be persuasive.
Talking about the introduction page, a few do/don't do are a bit odd from my point of view: * in the “Carrying dependencies” sample, public inheritance is replaced by composition. Unless the code was badly broken in the first place (ie, using public inheritance where it shouldn't have), it's very unlikely that such a change can usually be applied. A possible fix would at least be to switch to private inheritance in the initial (bad) code. * in the “Carrying injector” sample, it is stated that “Service locator is consider to be an anti-pattern because its instance is required to be passed as the ONLY constructor parameter into all constructors”. I don't know where that statement come from – and some code bases i've worked with disagree with that statement. There's much to say about the service locator pattern, though, and DI is probably a better alternative, but i need to be convinced on solid bases. * the “Manual DI - Wiring Mess” is the part i'd like to see expanded. Typically, with the given example, i don't get a clue on how i replace “view” with another implementation. Which, as far as i'm concerned, is the strong point of DI. The mocks provider sample gives an answer, IMHO it ought to be in the introduction. Besides, the library looks indeed very interesting. Regards, Julien