Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111293 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 14947 invoked from network); 3 Aug 2020 05:52:22 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 3 Aug 2020 05:52:22 -0000 To: internals@lists.php.net References: Date: Mon, 3 Aug 2020 05:49:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: Feature Request: dependencies container From: marandall@php.net (Mark Randall) Message-ID: 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