Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111292
MIME-Version: 1.0
References: <CAM0Ccxi7T+T=18YjtQX44j3Rh2S+m09zL+ypmvP0VYjt-CsvyQ@mail.gmail.com>
 <CADyq6sKKAotECdg=8oQ-BjKQesgL1=aUsXEavOTwXw2GQ2jPYA@mail.gmail.com> <CAM0Ccxi5O4oUSKRTvOJuhj5AA33KvKMpLV53X2A0=veT7USm=Q@mail.gmail.com>
In-Reply-To: <CAM0Ccxi5O4oUSKRTvOJuhj5AA33KvKMpLV53X2A0=veT7USm=Q@mail.gmail.com>
Date: Mon, 3 Aug 2020 06:28:23 +0200
Message-ID: <CADyq6s+1p_E121a7wZTSw=20rEAcChkcZ2JVMHXNUqbGeyZuvQ@mail.gmail.com>
To: 3u93n3 <zsidelnik@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000677bcd05abf1929a"
Subject: Re: [PHP-DEV] Feature Request: dependencies container
From: ocramius@gmail.com (Marco Pivetta)

--000000000000677bcd05abf1929a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =
=F0=9F=91=8D
>
> 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 =F0=9F=91=8D

Alternatively, you can check the gazillion pre-existing DICs out there:
auryn probably doing what you want, but with much healthier structure.

>

--000000000000677bcd05abf1929a--