Skip to content

Application class with no macro/template magic #723

@scravy

Description

@scravy

Opening a discussion based on #721 (comment) – intially commented on by @kostyantyn

I have a general question. Why do we need macros for injector? What is the critical improvement it gives us that we should go with the macro and preprocessor logic over simple C++ syntax?

What if we had a class, let's say Application (like UnitEInjector now) which in its constructor initializes each component in the same order we have now and in the destructor invokes the delete on each object in the correct order?

pseudo code:

class Application {
public:

Application() {
  m_state_register = new StateRegisterImpl();
  m_state_processor = new StateRegisterImpl(m_state_register);
  // ...
}

~Application() {
  delete m_state_processor;
  delete m_state_register;
}

StateRegister GetStateRegister() { return m_state_register; }
StateProcessor GetStateProcessor() { return m_state_processor; }

private:
  StateRegister *m_state_register;
  StateProcessor *m_state_register;
}

I see that with macro we don't need to write initializer, deinitializer and getter methods so it's an improvement. But having a bit of boilerplate (we don't create new components often, and at the code review we can check that they are initialized properly), we would have a simple C++ syntax.

Then we don't need templated GetCompoment function, we would just call g_application.GetStateProcessor() for instance. Then we don't need Dependency<...> alias, we will direcrly use * or unique_ptr or whatever the reference is.

Metadata

Metadata

Assignees

No one assigned

    Labels

    brainstormingNeeds input, ideas are welcome

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions