Proposal: Meta information for container objects

[davydovanton]

I think it'll be helpful to store some meta-information about dependency in a container. Some ideas where you can use this information:

• Aliases for DI frameworks (dry-auto_inject in our case);
• Store graph of all dependencies in a dependency. After we can calculate what we need to load and check before current dep and it will provide to detect "dependency deadlock" (when A dependency load B dependency and B dependency load A);
• Rules for DI framework (hello java). For example, it can allow loading dependency in specific scope:

container.register('users.repositories.users', only_in: 'users.operations.*') { ... }

module Books
  module Operations
    class Create
      include Import['users.repositories.users'] # => raise error on booting
    end
  end
end

• Passing context into dependencies
• Etc

WDYT? I can implement simple PoC for meta information, and after that we can start play with it if you like the idea

[solnic]

👍 to meta-data and anything that's needed for better instrospection capabilities. When it comes to aliases and rules, I'm not sure to be honest. How would aliases work? In dry-auto_inject, it's configured per-constructor (so every object can ask for its own aliases for its deps). Rules sound intriguing but I don't know what kind of use cases it covers. I recently built an ACL system on top of container (from dry-system) so maybe this is something similar. You'd have to tell me more about what you're thinking :)

[davydovanton]

🎉 I think, next step for meta is understand what API we want to see in containers and how to store all this data.

Aliases: Just my idea but it can be helpful for avoid breaking changes. For example, we have hashid key in a container. If something changes and we introduce other hashid instance, for example, member_hashid we will update all this code in 2 steps. Change key to member_hashid and create an alias to hashid in the first iteration. And change hashid to member_hashid in all places without any problems in the next iteration.

Rules: for example, we have 2 different domains, books and users. We create users.repositories.users and what to use this repository in books domain. With rules, we can "protect" some not public domain dependencies for calling it from other domains.

[Morozzzko]

The idea looks interesting, however I have a question about rules

So we use only_in: in #register. How is it going to work with autoregistered items?

[davydovanton]

hey, have no idea now. But this first thing from my brain: we can use magic comments for set setting 🤔

[Morozzzko]

I thought about that too, but there's one issue with magic comments: the classes become aware of the container.

To be fair, we already have the auto_register: false magic comment, and that's fine.

I think we should just have a DSL to configure auto registered components