[boost-ext] Looking for Review Manager/s

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
Hi,

I just wanted to share, potentially useful for the Boost and C++ community,
libraries and ask if anyone would be willing to become a Review Manager for
any of them?

[boost-ext] (https://github.com/boost-ext) is a collection of C++ libraries
with aspirations to be included in Boost. Libraries can be characterized by:
* Modern C++ (>= C++14)
* Header/Single Module only
* No dependencies

ATM, [boost::ext] consists of four core libraries:

* DI - Dependency Injection Library
    overview:
      standard: C++14
      single header with no dependencies (neither STL nor Boost is required)
      release: 1.2.0 (first release - 2014)
      key features:
        - supports macro-free constructor injection
        - supports templates injection
        - quick compilation-times
        - highly optimized code generation
    try it online: https://godbolt.org/z/5qTKhf
    source code: https://github.com/boost-ext/di
    documentation: https://boost-ext.github.io/di/

* SML - State Machine Library
    overview:
      standard: C++14
      single header with no dependencies (neither STL nor Boost is required)
      release: 1.1.4 (first release - 2016)
      key features:
        - much faster compilation-times than Boost.MSM (up to 60x faster)
        - highly optimized and customizable code generation
        - suitable for embedded systems
    try it online: https://godbolt.org/z/y99L50
    source code: https://github.com/boost-ext/sml
    documentation: https://boost-ext.github.io/sml/

* UT - Unit Testing Framework
    overview:
      standard: C++20
      single header with no dependencies (STL required)
      release: 1.1.8 (first release - 2019)
      key features:
        - macro-free
        - minimal boilerplate
        - fast compilation-times and execution
    try it online: https://godbolt.org/z/Jqb5Ye
    source code: https://github.com/boost-ext/ut
    documentation: https://boost-ext.github.io/ut

* TE - Run-time polymorphism (type erasure) library
    overview:
      standard: C++17
      single header with no dependencies (STL required)
      release: -
      key features:
        - simple interface
        - highly optimized code generation
    try it online: https://godbolt.org/z/xY9MEq
    source code: https://github.com/boost-ext/te
    documentation: https://github.com/boost-ext/te

All libraries (except TE) were successfully deployed in the production
systems.
Some, such as DI and SML are used by well known/big IT companies as well.

If anyone is interested in becoming a Review Manager for any of
the libraries, I'd really appreciate it and I'll more than happy to address
any issues/requests before the review as well as help with any
process-related tasks.

Thank you very much,
-Kris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
On Thu, 18 Feb 2021 at 20:58, Krzysztof Jusiak via Boost <
[hidden email]> wrote:

> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++
> libraries
> with aspirations to be included in Boost. Libraries can be characterized
> by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.2.0 (first release - 2014)
>       key features:
>         - supports macro-free constructor injection
>         - supports templates injection
>         - quick compilation-times
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/5qTKhf
>     source code: https://github.com/boost-ext/di
>     documentation: https://boost-ext.github.io/di/
>
> * SML - State Machine Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.1.4 (first release - 2016)
>       key features:
>         - much faster compilation-times than Boost.MSM (up to 60x faster)
>         - highly optimized and customizable code generation
>         - suitable for embedded systems
>     try it online: https://godbolt.org/z/y99L50
>     source code: https://github.com/boost-ext/sml
>     documentation: https://boost-ext.github.io/sml/
>
>
Oh! I've been interested in SML for some time. Great!


> * UT - Unit Testing Framework
>     overview:
>       standard: C++20
>       single header with no dependencies (STL required)
>       release: 1.1.8 (first release - 2019)
>       key features:
>         - macro-free
>         - minimal boilerplate
>         - fast compilation-times and execution
>     try it online: https://godbolt.org/z/Jqb5Ye
>     source code: https://github.com/boost-ext/ut
>     documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>     overview:
>       standard: C++17
>       single header with no dependencies (STL required)
>       release: -
>       key features:
>         - simple interface
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/xY9MEq
>     source code: https://github.com/boost-ext/te
>     documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2/18/2021 2:57 PM, Krzysztof Jusiak via Boost wrote:

> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++ libraries
> with aspirations to be included in Boost. Libraries can be characterized by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>      overview:
>        standard: C++14
>        single header with no dependencies (neither STL nor Boost is required)
>        release: 1.2.0 (first release - 2014)
>        key features:
>          - supports macro-free constructor injection
>          - supports templates injection
>          - quick compilation-times
>          - highly optimized code generation
>      try it online: https://godbolt.org/z/5qTKhf
>      source code: https://github.com/boost-ext/di
>      documentation: https://boost-ext.github.io/di/
>
> * SML - State Machine Library
>      overview:
>        standard: C++14
>        single header with no dependencies (neither STL nor Boost is required)
>        release: 1.1.4 (first release - 2016)
>        key features:
>          - much faster compilation-times than Boost.MSM (up to 60x faster)
>          - highly optimized and customizable code generation
>          - suitable for embedded systems
>      try it online: https://godbolt.org/z/y99L50
>      source code: https://github.com/boost-ext/sml
>      documentation: https://boost-ext.github.io/sml/
>
> * UT - Unit Testing Framework
>      overview:
>        standard: C++20
>        single header with no dependencies (STL required)
>        release: 1.1.8 (first release - 2019)
>        key features:
>          - macro-free
>          - minimal boilerplate
>          - fast compilation-times and execution
>      try it online: https://godbolt.org/z/Jqb5Ye
>      source code: https://github.com/boost-ext/ut
>      documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>      overview:
>        standard: C++17
>        single header with no dependencies (STL required)
>        release: -
>        key features:
>          - simple interface
>          - highly optimized code generation
>      try it online: https://godbolt.org/z/xY9MEq
>      source code: https://github.com/boost-ext/te
>      documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris

I like the testing framework, even if it is for C ++20 only. While I
have used both Boost Test and lightweight test I admit that your more
"natural" testing syntax is quite appealing.

I will admit that your example-driven documentation approach does not
appeal to me in general, but evidently most programmers like it. I
would, however, suggest you attempt to explain the reason why anyone
would want to use your DI, SML, and TE libraries, ie. how does using any
of these libraries actually benefit a C++ programmer. Other than the
"wow" factor I need a well thought out reason that I can understand to
use a library in my own code. I am glad to see you are using the
features of C++14 on up to provide different versions of state machine
and type erasure than are currently in Boost.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2/18/21 11:57 AM, Krzysztof Jusiak via Boost wrote:

>
> * DI - Dependency Injection Library
>
> * SML - State Machine Library
>      overview:
> * UT - Unit Testing Framework
>
> * TE - Run-time polymorphism (type erasure) library
>      overview:
>All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.

It sounds like you are proposing admission to boost of all these
libraries as a group. That is, I would expect this to be 4 separate
libraries, each with it's own review, documentation etc.  Am I missing
something here?

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 18/02/2021 19:57, Krzysztof Jusiak via Boost wrote:

> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?

I think you've waited long enough. I volunteer to review manage proposed
Boost.DI.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, 18 Feb 2021 at 20:58, Krzysztof Jusiak via Boost <
[hidden email]> wrote:

> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++
> libraries
> with aspirations to be included in Boost. Libraries can be characterized
> by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.2.0 (first release - 2014)
>       key features:
>         - supports macro-free constructor injection
>         - supports templates injection
>         - quick compilation-times
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/5qTKhf
>     source code: https://github.com/boost-ext/di
>     documentation: https://boost-ext.github.io/di/
>
> * SML - State Machine Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.1.4 (first release - 2016)
>       key features:
>         - much faster compilation-times than Boost.MSM (up to 60x faster)
>         - highly optimized and customizable code generation
>         - suitable for embedded systems
>     try it online: https://godbolt.org/z/y99L50
>     source code: https://github.com/boost-ext/sml
>     documentation: https://boost-ext.github.io/sml/
>
>
I have experimented with SML in the past and liked it.
If it were *proposed* for inclusion, I would be happy to *second* the
proposal in line with the published review process (link below).

https://www.boost.org/development/submissions.html#Seconded



> * UT - Unit Testing Framework
>     overview:
>       standard: C++20
>       single header with no dependencies (STL required)
>       release: 1.1.8 (first release - 2019)
>       key features:
>         - macro-free
>         - minimal boilerplate
>         - fast compilation-times and execution
>     try it online: https://godbolt.org/z/Jqb5Ye
>     source code: https://github.com/boost-ext/ut
>     documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>     overview:
>       standard: C++17
>       single header with no dependencies (STL required)
>       release: -
>       key features:
>         - simple interface
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/xY9MEq
>     source code: https://github.com/boost-ext/te
>     documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi,

Just wanted to apologize for all the headache/additional work I've caused
for the Boost Steering Committee and for all the confusion I caused to the
users because of using the boost name.
It never was my intention to do so and I'm sorry for screwing it up.

After talking with Glen Fernandes we have found a path forward and I
already started working on it to fix as much damage as possible
- The boost logo has been removed from https://github.com/boost-ext
- All advertisements/talks won't include boost name
- Additionally, all libraries already have ext namespace and disclaimer
that they aren't part of Boost libraries
- External packages will not include boost as well (existing packages will
be either removed or changed)

Conan
- di - https://conan.io/center/di - seems good
- ut - https://conan.io/center/boost-ext-ut - (to be changed)
- sml - https://github.com/conan-io/conan-center-index/pull/4591 (in
progress, added a comment to ensure it will be called sml without boost)

Vcpkg
- di - https://github.com/microsoft/vcpkg/tree/master/ports/boost-di (to be
changed)
- ut - not added
- sml - not added

My apologies again and please let me know what else I can do and/or see any
other resource which has to be changed.

Thank you, Kris

On Thu, Feb 18, 2021 at 12:57 PM Krzysztof Jusiak <[hidden email]>
wrote:

> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++
> community, libraries and ask if anyone would be willing to become a Review
> Manager for any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++
> libraries with aspirations to be included in Boost. Libraries can be
> characterized by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.2.0 (first release - 2014)
>       key features:
>         - supports macro-free constructor injection
>         - supports templates injection
>         - quick compilation-times
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/5qTKhf
>     source code: https://github.com/boost-ext/di
>     documentation: https://boost-ext.github.io/di/
>
> * SML - State Machine Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.1.4 (first release - 2016)
>       key features:
>         - much faster compilation-times than Boost.MSM (up to 60x faster)
>         - highly optimized and customizable code generation
>         - suitable for embedded systems
>     try it online: https://godbolt.org/z/y99L50
>     source code: https://github.com/boost-ext/sml
>     documentation: https://boost-ext.github.io/sml/
>
> * UT - Unit Testing Framework
>     overview:
>       standard: C++20
>       single header with no dependencies (STL required)
>       release: 1.1.8 (first release - 2019)
>       key features:
>         - macro-free
>         - minimal boilerplate
>         - fast compilation-times and execution
>     try it online: https://godbolt.org/z/Jqb5Ye
>     source code: https://github.com/boost-ext/ut
>     documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>     overview:
>       standard: C++17
>       single header with no dependencies (STL required)
>       release: -
>       key features:
>         - simple interface
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/xY9MEq
>     source code: https://github.com/boost-ext/te
>     documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Krzysztof Jusiak wrote:
...

> * DI - Dependency Injection Library

> * SML - State Machine Library

> * UT - Unit Testing Framework

> * TE - Run-time polymorphism (type erasure) library

I'm not sure how I feel about two-letter library (hence directory, repo)
names. SML is fine, but maybe we can have proper names (or at least TLAs)
for the other three? E.g. Boost.Inject for DI, or something like that. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
I do not believe I have the expertise to be a review manager on any of
these, but I have toyed with SML and looked at TE and find both to be
of very good quality.
Having those libraries in would be a nice boost for boost.

/Peter

On Thu, Feb 18, 2021 at 8:57 PM Krzysztof Jusiak via Boost
<[hidden email]> wrote:

>
> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++ libraries
> with aspirations to be included in Boost. Libraries can be characterized by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is required)
>       release: 1.2.0 (first release - 2014)
>       key features:
>         - supports macro-free constructor injection
>         - supports templates injection
>         - quick compilation-times
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/5qTKhf
>     source code: https://github.com/boost-ext/di
>     documentation: https://boost-ext.github.io/di/
>
> * SML - State Machine Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is required)
>       release: 1.1.4 (first release - 2016)
>       key features:
>         - much faster compilation-times than Boost.MSM (up to 60x faster)
>         - highly optimized and customizable code generation
>         - suitable for embedded systems
>     try it online: https://godbolt.org/z/y99L50
>     source code: https://github.com/boost-ext/sml
>     documentation: https://boost-ext.github.io/sml/
>
> * UT - Unit Testing Framework
>     overview:
>       standard: C++20
>       single header with no dependencies (STL required)
>       release: 1.1.8 (first release - 2019)
>       key features:
>         - macro-free
>         - minimal boilerplate
>         - fast compilation-times and execution
>     try it online: https://godbolt.org/z/Jqb5Ye
>     source code: https://github.com/boost-ext/ut
>     documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>     overview:
>       standard: C++17
>       single header with no dependencies (STL required)
>       release: -
>       key features:
>         - simple interface
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/xY9MEq
>     source code: https://github.com/boost-ext/te
>     documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
czw., 18 lut 2021 o 20:58 Krzysztof Jusiak via Boost <[hidden email]>
napisał(a):

> Hi,
>
> I just wanted to share, potentially useful for the Boost and C++ community,
> libraries and ask if anyone would be willing to become a Review Manager for
> any of them?
>
> [boost-ext] (https://github.com/boost-ext) is a collection of C++
> libraries
> with aspirations to be included in Boost. Libraries can be characterized
> by:
> * Modern C++ (>= C++14)
> * Header/Single Module only
> * No dependencies
>
> ATM, [boost::ext] consists of four core libraries:
>
> * DI - Dependency Injection Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.2.0 (first release - 2014)
>       key features:
>         - supports macro-free constructor injection
>         - supports templates injection
>         - quick compilation-times
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/5qTKhf
>     source code: https://github.com/boost-ext/di
>     documentation: https://boost-ext.github.io/di/


Regarding the DI library, I read the introduction and the tutorial part,
and it does not help me understand what problem this library solves or why
I should use it. Is there some other way to explain what this library is
for?
Or maybe I need to switch my mindset to Java-like OO patterns a la GoF in
order to appreciate this?
Is there a lot of theory that I have to learn prior to be able to
understand what it is for?

The docs give this example:

auto injector = di::make_injector();
  injector.create<app>();

Does this create a temporary object of type `app` that vanishes
momentarily? Or is there some magical object lifetime management going on
behind the scenes?

Also, it looks like it will only work if the leaves of this dependency tree
are default-constructible and if I am happy with calling default
constructors. But usually I am not: I need to pass arguments to my objects,
even if they are leaves in the dependency tree.

I would appreciate help in understanding the motivation.

Regards,
&rzej;

>
>
> * SML - State Machine Library
>     overview:
>       standard: C++14
>       single header with no dependencies (neither STL nor Boost is
> required)
>       release: 1.1.4 (first release - 2016)
>       key features:
>         - much faster compilation-times than Boost.MSM (up to 60x faster)
>         - highly optimized and customizable code generation
>         - suitable for embedded systems
>     try it online: https://godbolt.org/z/y99L50
>     source code: https://github.com/boost-ext/sml
>     documentation: https://boost-ext.github.io/sml/
>
> * UT - Unit Testing Framework
>     overview:
>       standard: C++20
>       single header with no dependencies (STL required)
>       release: 1.1.8 (first release - 2019)
>       key features:
>         - macro-free
>         - minimal boilerplate
>         - fast compilation-times and execution
>     try it online: https://godbolt.org/z/Jqb5Ye
>     source code: https://github.com/boost-ext/ut
>     documentation: https://boost-ext.github.io/ut
>
> * TE - Run-time polymorphism (type erasure) library
>     overview:
>       standard: C++17
>       single header with no dependencies (STL required)
>       release: -
>       key features:
>         - simple interface
>         - highly optimized code generation
>     try it online: https://godbolt.org/z/xY9MEq
>     source code: https://github.com/boost-ext/te
>     documentation: https://github.com/boost-ext/te
>
> All libraries (except TE) were successfully deployed in the production
> systems.
> Some, such as DI and SML are used by well known/big IT companies as well.
>
> If anyone is interested in becoming a Review Manager for any of
> the libraries, I'd really appreciate it and I'll more than happy to address
> any issues/requests before the review as well as help with any
> process-related tasks.
>
> Thank you very much,
> -Kris
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
On Fri, Feb 19, 2021 at 1:27 PM Andrzej Krzemienski via Boost <
[hidden email]> wrote:

> czw., 18 lut 2021 o 20:58 Krzysztof Jusiak via Boost <
> [hidden email]>
> napisał(a):
>
> > Hi,
> >
> > I just wanted to share, potentially useful for the Boost and C++
> community,
> > libraries and ask if anyone would be willing to become a Review Manager
> for
> > any of them?
> >
> > [boost-ext] (https://github.com/boost-ext) is a collection of C++
> > libraries
> > with aspirations to be included in Boost. Libraries can be characterized
> > by:
> > * Modern C++ (>= C++14)
> > * Header/Single Module only
> > * No dependencies
> >
> > ATM, [boost::ext] consists of four core libraries:
> >
> > * DI - Dependency Injection Library
> >     overview:
> >       standard: C++14
> >       single header with no dependencies (neither STL nor Boost is
> > required)
> >       release: 1.2.0 (first release - 2014)
> >       key features:
> >         - supports macro-free constructor injection
> >         - supports templates injection
> >         - quick compilation-times
> >         - highly optimized code generation
> >     try it online: https://godbolt.org/z/5qTKhf
> >     source code: https://github.com/boost-ext/di
> >     documentation: https://boost-ext.github.io/di/
>
>
> Regarding the DI library, I read the introduction and the tutorial part,
> and it does not help me understand what problem this library solves or why
> I should use it. Is there some other way to explain what this library is
> for?
>

I was hoping that the explantation from https://boost-ext.github.io/di/boost
is good enough but I understand it might be confusing.
DI is a very simple concept, actually. The main point is to make the code
less coupled by injecting dependencies which is usually done by passing
them through constructors.
I'd hope that the following talk -
https://www.youtube.com/watch?v=yVogS4NbL6U is a good explanation of DI as
well. I'm happy to follow-up in any form, though.


> Or maybe I need to switch my mindset to Java-like OO patterns a la GoF in
> order to appreciate this?
>

Right, Dependency Injection is related to OO patterns and especially the
SOLI-D (Dependency Inversion) principle.


> Is there a lot of theory that I have to learn prior to be able to
> understand what it is for?
>

Not sure, OO, SOLID should be more than enough, IMHO.


>
> The docs give this example:
>
> auto injector = di::make_injector();
>   injector.create<app>();
>
> Does this create a temporary object of type `app` that vanishes
> momentarily? Or is there some magical object lifetime management going on
> behind the scenes?
>

That will depend on the scope. By default, it's a singleton scope so the
app will have the same lifetime as the program.

Some useful information can be found:
- https://boost-ext.github.io/di/user_guide.html#scopes
- https://boost-ext.github.io/di/tutorial.html


> Also, it looks like it will only work if the leaves of this dependency tree
> are default-constructible and if I am happy with calling default
> constructors. But usually I am not: I need to pass arguments to my objects,
> even if they are leaves in the dependency tree.
>
> DI deduces constructor parameters automatically so it works with
non-default-constructible types as well.
DI is capable of creating the whole dependency tree.

Potential examples which can maybe help
-
https://github.com/boost-ext/di/blob/cpp14/example/tutorial/basic_create_objects_tree.cpp
- https://github.com/boost-ext/di/blob/cpp14/example/motivation.cpp
- https://github.com/boost-ext/di/tree/cpp14/example/polymorphism


> I would appreciate help in understanding the motivation.
>

I hope that the examples and explanation helps a bit, but if not I'm also
more than happy/available to have a follow-up (via zoom or similar) if that
helps (feedback could be used to improve the documentation)?


> Regards,
> &rzej;
>
> >
> >
> > * SML - State Machine Library
> >     overview:
> >       standard: C++14
> >       single header with no dependencies (neither STL nor Boost is
> > required)
> >       release: 1.1.4 (first release - 2016)
> >       key features:
> >         - much faster compilation-times than Boost.MSM (up to 60x faster)
> >         - highly optimized and customizable code generation
> >         - suitable for embedded systems
> >     try it online: https://godbolt.org/z/y99L50
> >     source code: https://github.com/boost-ext/sml
> >     documentation: https://boost-ext.github.io/sml/
> >
> > * UT - Unit Testing Framework
> >     overview:
> >       standard: C++20
> >       single header with no dependencies (STL required)
> >       release: 1.1.8 (first release - 2019)
> >       key features:
> >         - macro-free
> >         - minimal boilerplate
> >         - fast compilation-times and execution
> >     try it online: https://godbolt.org/z/Jqb5Ye
> >     source code: https://github.com/boost-ext/ut
> >     documentation: https://boost-ext.github.io/ut
> >
> > * TE - Run-time polymorphism (type erasure) library
> >     overview:
> >       standard: C++17
> >       single header with no dependencies (STL required)
> >       release: -
> >       key features:
> >         - simple interface
> >         - highly optimized code generation
> >     try it online: https://godbolt.org/z/xY9MEq
> >     source code: https://github.com/boost-ext/te
> >     documentation: https://github.com/boost-ext/te
> >
> > All libraries (except TE) were successfully deployed in the production
> > systems.
> > Some, such as DI and SML are used by well known/big IT companies as well.
> >
> > If anyone is interested in becoming a Review Manager for any of
> > the libraries, I'd really appreciate it and I'll more than happy to
> address
> > any issues/requests before the review as well as help with any
> > process-related tasks.
> >
> > Thank you very much,
> > -Kris
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
On 19/02/2021 22:20, Krzysztof Jusiak via Boost wrote:

> I hope that the examples and explanation helps a bit, but if not I'm also
> more than happy/available to have a follow-up (via zoom or similar) if that
> helps (feedback could be used to improve the documentation)?

Kris I speak from experience with Outcome that you're going to have to
be much more hand holdy than that description you just gave. You'll need
to explain things in small, baby steps, because DI is one of those
things that nobody understands until the lightbulb switches on, and then
they totally get it.

Given that Mr. Dimov and several others have indicated they don't
understand the motivation behind DI, if you want to see DI get into
Boost, you're going to have to write a lot of personalised responses to
people and keep repeating yourself to each individual in turn until
people twig what DI is and why it's useful. I did this for Outcome, and
whilst it was laborious at the time, I think it paid off in the end for
everybody here.

(Incidentally, I chose DI to review manage for a reason, I think this is
the first vocabulary library we've seen presented here since Outcome. I
am *very* much hoping its review isn't going to turn into thousands of
emails ...)


Andrzej, I'll give you my description of DI (which is not that of
Boost.DI). For certain kinds of problem solution, it can make sense to
turn inside out the traditional design of a C++ program i.e. place the
innards on the outside, and put what is normally outside into the
innards. You thus get an "inverted design" program.

Normally that's a bad idea, because maintenance is harder, it's anti
social to other engineers, and so on. Also, in C++, we typically use
template techniques such as CRTP for DI, we don't typically use
polymorphic techniques in this, but that's peculiar to C++ and not what
most languages do because they don't have powerful enough compile time
facilities.

For complex use cases, or where a fixed ABI is absolutely needed,
template based techniques are too painful to use to do DI, and for this
niche use case, a common runtime framework such as that of Boost.DI lets
arbitrary pieces of DI based code interoperate with one another in a
composable fashion.

This use case is probably even more niche than that for Outcome, which
maybe 15% of C++ developers would ever need to consider using. For
non-template DI, I would estimate less than 5% of C++ developers would
ever need to consider using it.

*However*, for where you do actually need runtime polymorphic DI, there
are very few good solutions to hand in C++, unlike in other major
languages. I think proposed Boost.DI could really fill that empty gap,
and for those few who need that gap filled, they _badly_ need it filled.
A standardised solution in this space would be particularly valuable.


Just to be clear, I was talking about DI in general above, I don't know
if Boost.DI is the correct, or sufficient, or best approach to solving
non-template DI in C++. That's for the review here to decide.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
On Sat, 20 Feb 2021 at 03:10, Niall Douglas via Boost <[hidden email]>
wrote:

> On 19/02/2021 22:20, Krzysztof Jusiak via Boost wrote:
>
> > I hope that the examples and explanation helps a bit, but if not I'm also



I’ve looked at the examples in the documentation.

DI seems to allow me to build an arbitrary tuple of objects and pass that
tuple as the argument to a constructor. DI will then match off items in my
tuple to constructor arguments by interface type.

In that sense it seems to allow me to use an arbitrary “bag” of parameters
to build another object provided sufficient arguments have a corresponding
item in the bag (by interface type).

Since this matching is at compile time, what do I gain by this rather than
simply passing the arguments directly?

Can you show an example where use of DI allows me to express code more
clearly than a hand-written call?

I can think of uses of a dynamic (run time) bag of argument objects, but
not compile time.

Thanks in advance.



> > more than happy/available to have a follow-up (via zoom or similar) if
> that
> > helps (feedback could be used to improve the documentation)?
>
> Kris I speak from experience with Outcome that you're going to have to
> be much more hand holdy than that description you just gave. You'll need
> to explain things in small, baby steps, because DI is one of those
> things that nobody understands until the lightbulb switches on, and then
> they totally get it.
>
> Given that Mr. Dimov and several others have indicated they don't
> understand the motivation behind DI, if you want to see DI get into
> Boost, you're going to have to write a lot of personalised responses to
> people and keep repeating yourself to each individual in turn until
> people twig what DI is and why it's useful. I did this for Outcome, and
> whilst it was laborious at the time, I think it paid off in the end for
> everybody here.
>
> (Incidentally, I chose DI to review manage for a reason, I think this is
> the first vocabulary library we've seen presented here since Outcome. I
> am *very* much hoping its review isn't going to turn into thousands of
> emails ...)
>
>
> Andrzej, I'll give you my description of DI (which is not that of
> Boost.DI). For certain kinds of problem solution, it can make sense to
> turn inside out the traditional design of a C++ program i.e. place the
> innards on the outside, and put what is normally outside into the
> innards. You thus get an "inverted design" program.
>
> Normally that's a bad idea, because maintenance is harder, it's anti
> social to other engineers, and so on. Also, in C++, we typically use
> template techniques such as CRTP for DI, we don't typically use
> polymorphic techniques in this, but that's peculiar to C++ and not what
> most languages do because they don't have powerful enough compile time
> facilities.
>
> For complex use cases, or where a fixed ABI is absolutely needed,
> template based techniques are too painful to use to do DI, and for this
> niche use case, a common runtime framework such as that of Boost.DI lets
> arbitrary pieces of DI based code interoperate with one another in a
> composable fashion.
>
> This use case is probably even more niche than that for Outcome, which
> maybe 15% of C++ developers would ever need to consider using. For
> non-template DI, I would estimate less than 5% of C++ developers would
> ever need to consider using it.
>
> *However*, for where you do actually need runtime polymorphic DI, there
> are very few good solutions to hand in C++, unlike in other major
> languages. I think proposed Boost.DI could really fill that empty gap,
> and for those few who need that gap filled, they _badly_ need it filled.
> A standardised solution in this space would be particularly valuable.
>
>
> Just to be clear, I was talking about DI in general above, I don't know
> if Boost.DI is the correct, or sufficient, or best approach to solving
> non-template DI in C++. That's for the review here to decide.
>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:

> Andrzej, I'll give you my description of DI (which is not that of
> Boost.DI). For certain kinds of problem solution, it can make sense to
> turn inside out the traditional design of a C++ program i.e. place the
> innards on the outside, and put what is normally outside into the innards.
> You thus get an "inverted design" program.

[...]

I think what I'm missing most here is concrete examples of specific problems
that DI in general, and Boost.DI in particular, solve.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] Looking for Review Manager/s

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Krzysztof Jusiak wrote:
>    documentation: https://boost-ext.github.io/di/

This brings up one pretty obvious question, what if I have two constructor
parameters of the same type:

struct X
{
    std::string name;
};

struct Y
{
    std::string title;
};

struct Z
{
    X x;
    Y y;
};

How do I inject specific values for X::name and Y::title?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 20/02/2021 16:27, Peter Dimov via Boost wrote:

> Niall Douglas wrote:
>
>> Andrzej, I'll give you my description of DI (which is not that of
>> Boost.DI). For certain kinds of problem solution, it can make sense to
>> turn inside out the traditional design of a C++ program i.e. place the
>> innards on the outside, and put what is normally outside into the
>> innards. You thus get an "inverted design" program.
>
> [...]
>
> I think what I'm missing most here is concrete examples of specific
> problems that DI in general, and Boost.DI in particular, solve.

I agree that it's on the library proposer to convince everybody here of
the value add of the technique, and then his proposed solution.

Vocab libraries often struggle with communication, because what they
solve is so fundamental. It's a steep hill to climb, but necessary to
get such a library into Boost.

Kris I don't suppose you can rustle of somebody who is using DI in
production and would be willing to either open source that code, or come
here to describe how DI solved a pain point for them?

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
FWIW I did look at the documentation for DI.  I was quite pleased with
it.  Here are the things I liked:

a) there was a lot effort invested in organizing the docs.
b) they were quite readable
c) I liked the small examples help me understand this.  I've been
exposed to the idea of DI in the past and I could never figure out what
it was and what the purpose was.
d) I liked the physical layout - very consistent with other boost
libraries.  (I've become skeptical of the usage of other system.  They
don't really add much in my view - other than one more of way of doing
things.)

All this is very good.

BUT

a) I was left with the feeling that I sort of understood it but could
figure it out if I spent more time at it.  This is generally better than
I respond to most library documentation.

b) Same goes for the motivation / use case for the library.  What
problem does it solve, how does it compare with other solutions, etc.

So I felt we were 90% there.

My personal experience in the past has made me a little gun shy.  When I
get to this point in my own work, I sometimes find getting that last 10%
ends up being impossible.  This usually turns out that that my
"solution" - though it looks good - has some flaws that I didn't really
understand myself. I was blind to them. Only when I try to reconcile the
anomalies in the documentation does it become apparent that I've over
looked some subtle aspect in the library.  Could be conceptual side
effects, conflict with other ideas that the library uses, or perhaps it
adds more conceptual overhead then the library itself eliminates.  Or
something.

This is the basis of my recommendation that ping-pong between writing
code, examples, tests is under-appreciated as a contributor to good
software.

Sorry I can't be more helpful - the whole subject is sort of confusing
to me.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
sob., 20 lut 2021 o 03:10 Niall Douglas via Boost <[hidden email]>
napisał(a):

> On 19/02/2021 22:20, Krzysztof Jusiak via Boost wrote:
>
> > I hope that the examples and explanation helps a bit, but if not I'm also
> > more than happy/available to have a follow-up (via zoom or similar) if
> that
> > helps (feedback could be used to improve the documentation)?
>
> Kris I speak from experience with Outcome that you're going to have to
> be much more hand holdy than that description you just gave. You'll need
> to explain things in small, baby steps, because DI is one of those
> things that nobody understands until the lightbulb switches on, and then
> they totally get it.
>
> Given that Mr. Dimov and several others have indicated they don't
> understand the motivation behind DI, if you want to see DI get into
> Boost, you're going to have to write a lot of personalised responses to
> people and keep repeating yourself to each individual in turn until
> people twig what DI is and why it's useful. I did this for Outcome, and
> whilst it was laborious at the time, I think it paid off in the end for
> everybody here.
>

Yes. My recollection of the adventure with Outcome is similar. I guess it
takes time and energy to explain one's idea to others. I imagine it is
frustrating too. One writes a library, makes an effort to share it with the
people, and the only response back is, "do more work, convince us".


> (Incidentally, I chose DI to review manage for a reason, I think this is
> the first vocabulary library we've seen presented here since Outcome. I
> am *very* much hoping its review isn't going to turn into thousands of
> emails ...)
>
>
> Andrzej, I'll give you my description of DI (which is not that of
> Boost.DI). For certain kinds of problem solution, it can make sense to
> turn inside out the traditional design of a C++ program i.e. place the
> innards on the outside, and put what is normally outside into the
> innards. You thus get an "inverted design" program.
>
> Normally that's a bad idea, because maintenance is harder, it's anti
> social to other engineers, and so on. Also, in C++, we typically use
> template techniques such as CRTP for DI, we don't typically use
> polymorphic techniques in this, but that's peculiar to C++ and not what
> most languages do because they don't have powerful enough compile time
> facilities.
>
> For complex use cases, or where a fixed ABI is absolutely needed,
> template based techniques are too painful to use to do DI, and for this
> niche use case, a common runtime framework such as that of Boost.DI lets
> arbitrary pieces of DI based code interoperate with one another in a
> composable fashion.
>
> This use case is probably even more niche than that for Outcome, which
> maybe 15% of C++ developers would ever need to consider using. For
> non-template DI, I would estimate less than 5% of C++ developers would
> ever need to consider using it.
>
> *However*, for where you do actually need runtime polymorphic DI, there
> are very few good solutions to hand in C++, unlike in other major
> languages. I think proposed Boost.DI could really fill that empty gap,
> and for those few who need that gap filled, they _badly_ need it filled.
> A standardised solution in this space would be particularly valuable.
>
>
> Just to be clear, I was talking about DI in general above, I don't know
> if Boost.DI is the correct, or sufficient, or best approach to solving
> non-template DI in C++. That's for the review here to decide.
>

So far, my understanding is the following. Please correct me, if I am
mischaracterizing the situation.

This library is not so much about Dependency Injection. Dependency
Injection is just a style of programming. The DI-library is rather about
managing the complexity that results from choosing to use Dependency
Injection.
Suppose I have a class like the following:

```
struct Point
{
  int x;
  int y;
};

struct Rect
{
  Point lowerLeft;
  Point upperRight;
};

class State
{
  Rect area;
  Point location;
  // invariant: location is inside area;
public:
  State(int left, int lo, int right, int hi, int x, int y) : area{{left,
lo}, {right, hi}}, location{x, y} {}
};

int main()
{
  State s{0, 0, 2, 2, 1, 1};
}
```

I do not like that I have to pass so many parameters, that in this
configuration can be easily confused. So, I want to apply the Dependency
Injection philosophy. I get:

class State
{
  Rect area;
  Point location;
  // invariant: location is inside area;
public:
  State(Rect a, Point loc) : area{a}, location{loc} {}
};

int main()
{
  State s{Rect{{0, 0}, {2, 2}}, Point{1, 1}};
}
```

Now, I choose to use the DI-library (this is where I have troubles with
understanding: why would I want to do that?). I get the following result:

```
int main()
{
  State s = di::make_injector().create<State>(0, 0, 2, 2, 1, 1);
}
```
And now I get back to the situation where I am passing six ints and can
easily confuse which int represents what.

I am pretty sure I am now unfairly mischaracterizing the library. But this
is what I get from the motivation and tutorial sections, and the
explanations I have seen so far. You cannot see this behavior in the
tutorial example that is using class `app`, because most of the types in
there are default-constructed or constructed from values that were
themselves (perhaps recursively) default-constructed. So it looks to me
that in order to appreciate this library, I have to make most of my types
default-constructible.

At which point am I missing something?

Regards,
&rzej;



> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
Andrzej Krzemienski wrote:
...

> So, I want to apply the Dependency Injection philosophy. I get:
>
> class State
> {
>   Rect area;
>   Point location;
>   // invariant: location is inside area;
> public:
>   State(Rect a, Point loc) : area{a}, location{loc} {}
> };
>
> int main()
> {
>   State s{Rect{{0, 0}, {2, 2}}, Point{1, 1}};
> }
> ```
>
> Now, I choose to use the DI-library (this is where I have troubles with
> understanding: why would I want to do that?).

You are thinking in C++ (value semantics) but you need to be thinking in
Java (reference semantics, OOP, object DAGs.) Suppose you need to have a
logger object

shared_ptr<ILogger> pl; // new FileLogger( log_file_name fn );

and a database connector object (which uses a logger to log things)

shared_ptr<IDbConn> pdb; // new MysqlDb( mysql_db_info mdi,
shared_ptr<ILogger> pl )

and an abstract configuration query interface, that can use an .ini file, or
a JSON file, or a database

shared_ptr<IConfig> pc; // new DbConfig( shared_ptr<IDbConn> pdb,
shared_ptr<ILogger> pl );

Now when you need to create the config query object, you need to give it a
database connector and a logger, and you also need to give the same logger
to the database connector. So with [NotYetBoost].DI you'll write something
like

auto injector = make_injector(
    bind<log_file_name>.to( "something.log" ),
    bind<ILogger>.to<FileLogger>(),
    bind<>.to( mysql_db_info{ ... } ),
    bind<IDbConn>.to<MysqlDb>(),
    bind<IConfig>.to<DbConfig>()
);

auto cfg = injector.create<IConfig>();

although I don't really know if this will compile or work. :-)

Now imagine that same thing but with 10 objects, or 20 objects. Also imagine
that your day to day vocabulary includes "business logic", "enterprise",
"UML" and "XML".


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost-ext] DI questions

Boost - Dev mailing list
Let me try to explain DI (manual and automatic) via example.

DI vs NO-DI is all about less coupling by injecting dependencies instead of.
It's often referred as a Hollywood prince - Don't call us we will call you!

Example

struct coupled_no_di {
  void api() {
    d.call();
  }
  depedency d{singleton::get()};
};

- Coupled design (hard to test)

struct not_coupled_di {
  not_coupled_di(dependency& d) : d_{d} {}

  void api() {
    d.call();
  }
  depedency& d;
};

- Much better - separation of business logic and object creation.

But we can do even better by applying
- Dependency Inversion (relay on abstractions and not concrete
implementations)
- Abstractions can be done in many different ways (type erasure, templates,
abstract classes, etc.)

template<DependencyConcept TDependency>
struct not_coupled_di {
  not_coupled_di(TDependency& d) : d_{d} {}

  void api() {
    d.call();
  }
  TDependency& d;
};

The above is much better because
- It's not coupled to any specific implementation
- Can be changed for testing (mocks/fakes/stubs)

Okay, now let's take at the main. A good design will apply a Composition
Root (unique place in the app when dependencies are being created)

int main() {
  my_depedency dependency{...};
  not_coupled_di di{dependency};

  di.api();
}

- The above is an example of manual DI which is cool already but may lead
to what is called a Wiring Mess.

Let's imagine that we have a big dependency tree because we are following
SOLID principle and we especially apply the Single Responsibility Principle
(we will have a lot of dependencies).

int main() {
  my_dependency_1 d1{};
  my_dependency_2 d2{};
  my_dependency_3 d2{d1, d2};
  my_dependency_4 d3{d1, 42, d3};
  app a{d3, ...};
  ...

  // Order of the above is important and with bigger projects might be
easily 10k LOC+
}

- Well, we can maintain the above if we want, but Automatic DI will let us
actually focus on the business logic instead!
- Any change in the constructors (a reference to shared_pointer, the order
of parameters) will require us to change the above :(

Boost.DI library can help with removing the Wiring Mess for us, though!

int main() {
  auto injector = make_injector();
  app = create<app>(injector);
  return app.api();
}

Right now the benefits of using the framework instead of manual DI
- If we change any constructor parameter or order of any dependency we
DON't have to change anything with DI framework

- Before
  not_coupled_di(TDependency& d);

- Refactor
  not_coupled_di(std::shared_ptr<TDependency>);

With manual DI the wiring has to be changed to pass the shared_ptr with
Boost.DI we don't have to change the wiring code at all.

Okay, but what about the polymorphism behaviour.
Boost.DI allows a different type of polymorphism. One can inject templates,
abstract classes, variant, type erasure etc.
More can be found here -
https://github.com/boost-ext/di/tree/cpp14/example/polymorphism.

Why that's important? Because it's a better design and makes testing easier
too.
How to do it with Boost.DI?

// configuration
auto module = make_injector(
  bind<interface>.to<implementation> // I'm not going to go into details,
but Boost.DI allows to inject TEMPLATES, abstract classes, etc...
);

// production, release
int main() {
  app = create<app>(module);
  return app.api();
}

// end 2 end testing
int main() {
  auto injector = di::make_injector(
    module(), // production wiring
    di::bind<interface>.to<mock> [override]
  );
  app = create<app>(module);
  return app.api();
}

- Great, we can test end 2 end with overriding some dependencies such as
time, database, networking, logging etc...
- We have a loosely coupled design!
- We don't have to change ANYTHING in the wiring code when we change the
dependency tree and/or any constructor parameters/order

I hope that helps a bit?

I also really encourage to take a quick look at which summaries concepts
behind DI.
- https://www.youtube.com/watch?v=yVogS4NbL6U

Thanks, Kris

On Sat, Feb 20, 2021 at 4:10 PM Peter Dimov via Boost <[hidden email]>
wrote:

> Andrzej Krzemienski wrote:
> ...
> > So, I want to apply the Dependency Injection philosophy. I get:
> >
> > class State
> > {
> >   Rect area;
> >   Point location;
> >   // invariant: location is inside area;
> > public:
> >   State(Rect a, Point loc) : area{a}, location{loc} {}
> > };
> >
> > int main()
> > {
> >   State s{Rect{{0, 0}, {2, 2}}, Point{1, 1}};
> > }
> > ```
> >
> > Now, I choose to use the DI-library (this is where I have troubles with
> > understanding: why would I want to do that?).
>
> You are thinking in C++ (value semantics) but you need to be thinking in
> Java (reference semantics, OOP, object DAGs.) Suppose you need to have a
> logger object
>
> shared_ptr<ILogger> pl; // new FileLogger( log_file_name fn );
>
> and a database connector object (which uses a logger to log things)
>
> shared_ptr<IDbConn> pdb; // new MysqlDb( mysql_db_info mdi,
> shared_ptr<ILogger> pl )
>
> and an abstract configuration query interface, that can use an .ini file,
> or
> a JSON file, or a database
>
> shared_ptr<IConfig> pc; // new DbConfig( shared_ptr<IDbConn> pdb,
> shared_ptr<ILogger> pl );
>
> Now when you need to create the config query object, you need to give it a
> database connector and a logger, and you also need to give the same logger
> to the database connector. So with [NotYetBoost].DI you'll write something
> like
>
> auto injector = make_injector(
>     bind<log_file_name>.to( "something.log" ),
>     bind<ILogger>.to<FileLogger>(),
>     bind<>.to( mysql_db_info{ ... } ),
>     bind<IDbConn>.to<MysqlDb>(),
>     bind<IConfig>.to<DbConfig>()
> );
>
> auto cfg = injector.create<IConfig>();
>
> although I don't really know if this will compile or work. :-)
>
> Now imagine that same thing but with 10 objects, or 20 objects. Also
> imagine
> that your day to day vocabulary includes "business logic", "enterprise",
> "UML" and "XML".
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123