Proposal: Meta information for container objects about dry-container

[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