You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
useElazar\Auryn\Container;
useAcme\SomeDependency;
$container = newContainer;
if ($container->has(SomeDependency::class)) {
// ...
}
$instance = $container->get(SomeDependency::class);
// All public methods of Auryn\Injector are available$instance = $container->make(SomeDependency::class);
While I agree with a lot of the discussion in this issue
regarding why new projects can use Auryn directly without a PSR-11
implementation, I do think that such an implementation can be useful for
integrating Auryn with third-party libraries that use PSR-11, such
as zend-expressive.
The implementation in this repository takes a small amount of liberty with this
passage from Section 1.1.2
of the PSR-11 specification:
has ... MUST return true if an entry identifier is known to the container
Auryn uses fully qualified names
for classes and interfaces to identify dependencies where most container
implementations use user-designated names. As such, it's possible for Auryn to
instantiate a class even if it contains no definitions for that class (e.g.
if the class has no required constructor parameters or if those parameters are
themselves instantiable classes).
Because of this, ContainerInterface->has() in this PSR-11
implementation will return true if either the underlying Auryn\Injector
instance has definitions for a requested class or interface or if a requested
class is defined and considered instantiable (i.e. is not abstract and has a
public implementation of __construct()). While some may view this as
technically incorrect, it seems consistent to me with the overall spirit and
intentions of the PSR-11 standard.