container-interop compatibility for Auryn
Switch branches/tags
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
src
tests
.gitignore
.travis.yml
LICENSE
README.md
composer.json
phpunit.xml.dist

README.md

auryn-container-interop

Build Status

PSR-11 compatibility for Auryn

License

This library is licensed under the MIT License.

Installation

Use composer.

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.

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.

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.

Development

To run the PHPUnit test suite:

composer run-script test