[eternalban]

The 'Env' is typically called 'Context'.

These mechanisms are addressing functional requirements in component oriented systems, but in the industry have been misunderstood and misused to satisfy testing requirements.

And if one is not doing pervasive component reuse across multiple systems and projects, the on-off usage of DI is of course completely over-engineered and likely a poor design decision.

[mrec]

And one obvious refinement of the `Env`/`Context` God-dependency pattern is to have it implement a bunch of fine-grained interfaces for subsets of the dependencies it aggregates, so that you can both reduce plumbing (only one thing to inject) and still make it clear which specific dependencies a given call might use.

[DaiPlusPlus]

How would you manage scoped lifetimes and transient objects using the Env/Context pattern?

[eternalban]

I creatd a minimal framework in C++ in mid '90s around the concept of Contextual Objects. Child contexts can be used to affect life-cycle scopes. In this approach, the virtual construct of a 'containment context' allows for managed life-cycles, at an aggregate level. Delete the context and all child objects (recursively) are deleted as well.