Skip to content

Policies and contextual bindings are broken. #579

@gitmodimo

Description

@gitmodimo

I have been experimenting with uml_dumper and some weird connections we made in dependency graph.
I made a deep dive into how it works and I believe that uml_dumper is fundamentally broken.
I will go into details in uml_dumper case but I believe this is also true for all policies and contextual bindings due to the same mechanism beeing used.

In uml_dumper parent-child relationship is based on std::vector<const std::type_info*> v = {&typeid(nullptr)};.
When first element is constructed it gets added to vector N=T::arity::value times. IIUC this is due to next N policies invocations would presumably be due to creation of current elements dependencies.
However this assumption is wrong in three major cases:

  1. A singleton is being used the second time - then singletons' dependencies are not created again, but the singleton is pushed to std::vector<const std::type_info*> v nevertheless. I tried fixing it with conditionally adding singletons only when they are not already on the list, but this seems to be flaky.
  2. Dynamic binding is used - then T::arity::value does not represent number of dependencies. AFAIK dynamic bindings may have dynamic number of dependencies.
  3. Multiple Bindings - T::arity::value would need to represent number of elements in vector, but it doesn't. Also uml_dumper does not compile when multiple bindings are used.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions