Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[5.7] [Option 1] Improve PSR-11 implementation #25870
I've recently tried to implement a small lib to bridge between a Laravel app and a legacy app and I finally understood why so many people tried to change the PSR-11 implementation, which frankly I got it quite wrong. Ref #25682, #25678, #21335, #21327, #19822 and laravel/ideas#803.
Let's look at the possibilities of
Right now, only option 1 and 2 works when using PSR-11 with Laravel container. Something has to explicitly bind into the Laravel container in order for it to work. If it was never bound before, it will not try to do anything. PSR-11 doesn't offer any way to bind things into the container, only resolve out of it.
1- It will resolve explicitly bound into their concrete.
If this patch gets applied, package developers can opt to ignore the
referenced this pull request
Oct 2, 2018
I think this
The try catch is a must-have anyway as PSR-11 specifies that
PSR-11 says this about the
Since Laravel's container has such great autowiring abilities there is no reason why the
IMO "get" is pretty straightforward. An item is fetched from the container. Autowiring "makes" an object. This seems outside the scope of psr-11. Which is why it is left up to the framework. Some containers handle autowiring differently, however, unless there is an "identifier" stored on the container explicitly, "get" doesn't seem to apply.
Seems like a nightmare of maintenance to make this work properly and address all of the edge cases
This is great feedback for PSR editors, which is beyond the scope of this PR. According to their statement, it's the container implementation's job to decide whether to do auto-wire for
@deleugpn I don't agree that PSR-11 only allows for answering the first two of the four distinctions you made.
Containers can autowire, but for those consuming the container, that is an implementation detail. Ideally, if autowiring is in place,
In zend-servicemanager, we have the concept of "abstract factories". These are factories that can produce zero or more instances, and the interface for these includes a method for testing if it can produce the requested instance. Abstract factories therefor provide us with autowiring, and allow our container to answer the last two of the bullet points you noted. (In point of fact, since version 3, zend-di now provides an abstract factory that can be consumed by zend-servicemanager, allowing it to provide reflection-based autowiring for any service!)
So, that's my long-winded way of saying I agree with @moufmouf here.
It would be a good idea for you to look at other PSR-11 implementations as you do this sort of work, as it can allow you to see how others have tackled the problem. I think you would have found early that most of them provide some way of autowiring.
Reading the PSR-11 spec:
There is no language there about if the container could hypothetically resolve some unknown class. It only states that that we should return a boolean value indicating if the identifier is known to us.
Something is not explicitly bound to the container is not known to us. We may be able to resolve it, we may not be able to. We don't KNOW if we can until we actually try it (or recursively reflect through every dependency down the chain) - and if we don't know until we try it, what is the point of the
I don't want to get deep into knocking on PSR-11 here but with an auto-wiring container that can resolve things that aren't explicitly bound, the
I guess I basically agree with the implementation you have here.
@taylorotwell I agree with your reasoning here. Although the PSR text doesn't say it, the editors have been saying that
The approach on this PR is different, though, we can just ignore the existence of
The problem with Laravel right now is that
Just for reference:
Another reason for the
In an auto-wiring, non-composite container,