|
Boost : |
From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2021-02-23 11:46:01
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk