Everything

php

Feature Request: dependencies container

php.internals

[ ]

6 years ago

The main idea is to take control over objects creation and injecting
dependencies.

1. Some of them are provided through constructor (those, which could only
be retrieved right before instantiating our object).
2. Others are provided through `__inject` and PHP will inject all those
dependencies automatically. Configuration we define in separate class, and
pass it's instance into function-helper.

More verbose explanation in attached file:

Marco Pivetta

6 years ago

Heya,

On Mon, Aug 3, 2020, 05:32 3u93n3 <zsidelnik@gmail.com> wrote:

> The main idea is to take control over objects creation and injecting
> dependencies.
>
> 1. Some of them are provided through constructor (those, which could only
> be retrieved right before instantiating our object).
> 2. Others are provided through `__inject` and PHP will inject all those
> dependencies automatically. Configuration we define in separate class, and
> pass it's instance into function-helper.
>

Overall, I don't think this is a good candidate for php-src 2 primary
reasons:

1. This is already possible in userland: you can already define your own
`__inject` method, and, convention-based, rely on it in your own userland
DIC
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 👍

Mark Randall

6 years ago

On 03/08/2020 04:31, 3u93n3 wrote:

> The main idea is to take control over objects creation and injecting
> dependencies.

Hi 3u93n3,

Thank you for the effort. However, it is generally accepted that this
kind of functionality belongs to userland rather than the core.

There are a few issues with this proposal:

1. It depends on global state (register_dependency_bindings) which is
something we aim to avoid as in the vast majority of cases it leads to
unfortunate outcomes and difficulty in maintaining code.

2. It introduces more language magic, and sentiment is generally against
more magic.

Most of all though, this problem has already been solved in userland by
instantiating objects via factories - no magic involved, just static code.

With (presumably) 8.0 and the introduction of attributes, existing
dependency injection frameworks will have additional methods of cleanly
expressing which constructor fields are injected, and which are user
supplied.

We might even expect that these frameworks will be updated to take
advantage of this and include automatically generated factories:

#[Service]
class Foo {
public function __construct(
#[Inject] Foo $foo,
#[Inject] Bar $bar,
string $value
) {
...
}
}

$container->factories(Foo::class)("value");

Mark Randall