Closed szepeviktor closed 3 years ago
This can be achieved with a very simple wrapper. As applications shouldn't know about the injector except for the bootstrapping phase, I personally don't see too much value in this specific PSR, but I also don't work with the usual frameworks.
What's needed in your opinion to make it PSR-11 friendly?
get
and has
methods and few lines in composer.json
Thinking about it, there's more to it than those two methods. As identifiers in PSR-11 are opaque, you'd have to be able to define things based on identifiers instead of types.
This was an old question in the old repo:
https://github.com/rdlowrey/auryn/issues/77 https://github.com/rdlowrey/auryn/issues/127
And there are two library borned to do that: https://github.com/elazar/auryn-container-interop https://github.com/northwoods/container
I don't know if they still work with the latest version of the Injector in this repo.
Thank you. It seems 1 hour of work.
As someone who used auryn since 2013 for multiple production apps, and someone who totally agrees on the ideology of auryn, I found it's always a nightmare to integrate 3rd party libraries that rely on PSR-11. That always made me do some adapters or implement one of the above links, this feels hacky and subject to get broken on injector upgrades.
Why don't we do a simple one class implementation via e.g. decorator pattern, that's used to serve as an adapter to PSR-11? Decorator, so you may still use the original instance of Injector elsewhere.
I think this was the most requested feature in the original repo
Anyone open for discussion? :)
I'll add it, but only after I added identifiers as a concept.
This has been implemented in the latest master branch. I'll probably take some time before it's released.
Thank you.
Please consider making the Injector PSR-11 friendly. https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-11-container.md
See https://github.com/thephpleague/container/blob/40aed0f11d16bc23f9d04a27acc3549cd1bb42ab/composer.json#L23-L35