Re: Feature Request: dependencies container

Re-writing with the internals ML in CC On Mon, Aug 3, 2020, 06:16 3u93n3 <zsidelnik@gmail.com> wrote: > > 2. Setter injection (as well as property injection, and also the > proposed __inject) leads to temporal coupling smells. Explained > otherwise, your object instances are not "functioning" right after > instantiation, which makes their API more complex and reduces reliability > (they are broken until injection has happened). Please just use the > constructor: it works, and it is a simple pre-existing injection point 👍 > > Please, read the attachment. __inject should be called right > before > __construct. Thus, objects are consistent. > In constructor we could use all injected dependencies. > Yes, I checked the document. The same problem applies, since you bow have an object that doesn't function anymore if not put in the context of a DIC. The design of the proposed DIC is not usable, because it proposes a singleton DIC that operates via register_dependency_bindings(...), and which overloads the new operator. In practice, by doing this, you are adding a lot of state and complexity to the language, since a new Foo() call can now implicitly mean that a global dependency binding is used to determine which parameters are passed to Foo#__inject(), which is almost as effective as code obfuscation. In addition to that, new Foo() may mean different things depending on the time at which it is called, since dependencies may have been changed in between. There's absolutely nothing wrong with passing your dependencies explicitly to your constructors: it makes the dependency graph clear. You can design the same concept of dependency resolver with an AST preprocessor and the current __construct() semantics 👍 Alternatively, you can check the gazillion pre-existing DICs out there: auryn probably doing what you want, but with much healthier structure. >