Ignore unspeciffied interaces when getting service by interface#6
Ignore unspeciffied interaces when getting service by interface#6koubas wants to merge 1 commit intoPHP-DI:masterfrom
Conversation
|
Hi there, thank you for the pull request. I had seen your fork earlier today and that's something that will be fixed soon (hopefully). The fix is here: PHP-DI/PHP-DI#169 The idea behind the fix is that PHP-DI shouldn't return My only reservation for the fix I wrote is detailed here: PHP-DI/PHP-DI#168 (comment). However the problem you faced is really bad, so I think I will merge it anyway. I'm swamped for the next couple of days but afterwards I'll have plenty of time, so this will be fixed! If you have time to write a small test that would be awesome, else I'll manage to do it later. |
|
Sorry it took some time. FYI I merged the bugfix into the 4.2 branch, so now I'll work on releasing the 4.2. |
|
FYI 4.2 was released yesterday |
2 participants
Hi, with current version I ran into trouble when getting a service, named with FQN of some interface. The service was provided by another abstract factory, but PHP-DI threw an exception in its AF, because it found that interface, but has no implementation mapped to it.
I had to override that behavior of PHP-DI to make canCreateServiceWithName method return FALSE in that case, instead of throwing an exception, and allow to pass the service resolution to other abstract factories that may provide that service.
If there is some simpler solution to determine, whether the interface can be injected by PHP-DI, or not, it woul be great.
Maybe we should implement some canCreate metohd to PHP-DI itself to be able to better determine, if we can create a service, without throwing/catching exceptions.
I'll try to provide some tests too