auryn-container-interop

, _(*1)

PSR-11 compatibility for Auryn, _(*2)

License

This library is licensed under the MIT License., _(*3)

Installation

Use composer., _(*4)

composer require elazar/auryn-container-interop

Usage

use Elazar\Auryn\Container;
use Acme\SomeDependency;

$container = new Container;

if ($container->has(SomeDependency::class)) {
    // ...
}

$instance = $container->get(SomeDependency::class);

// All public methods of Auryn\Injector are available
$instance = $container->make(SomeDependency::class);

Be sure you are familiar with how Auryn works. As recommended by its author, avoid using it as a service locator., _(*5)

Implementation

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., _(*6)

The implementation in this repository takes a small amount of liberty with this passage from Section 1.1.2 of the PSR-11 specification:, _(*7)

has ... MUST return true if an entry identifier is known to the container, _(*8)

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)., _(*9)

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., _(*10)