This document helps to upgrade users. It includes upgrading from 4.x to 5.x, but also still from 3.x to 4.x and from 2.x to 3.x.
Aura.Di 5.x is largely similar to 4.x, but there are some backwards-compatibility breaks, as well as some new features.
Constructing a Container
directly, without using the ContainerBuilder
, now requires a Resolver
, not an InjectionFactory
.
// old code
new Container(new InjectionFactory(new Resolver(new Reflector())));
// new code
new Container(new Resolver(new Reflector()));
There a few API changes in the objects. They probably do not have consequences for client libraries as they were not exposed publicly, but the changes are listed below nonetheless.
- The
InjectionFactory
now has no dependencies. TheResolver
is not injected anymore and thegetResolver()
andnewInstance()
methods have been removed. - The
LazyInterface
now requires aResolver
to be passed to__invoke
. Its implementations therefore also have different constructor signatures.
If you need an object that is directly invokable, without the need of passing a Resolver or any other object from the
container, use $container->lazyLazy()
to create an invokable object that is injectable into an external method or class.
$routeHandler = $di->lazyLazy(
$di->lazyCallable([
$di->lazyNew(OrderController::class),
'process'
])
);
In the above example $routeHandler
can be injected in any place that receives a callable
and can be called freely
without any further dependency on $container
.
Make sure you use the correct PHP version. This library uses the object type-hint and therefore requires PHP 8.0.
Aura.Di 4.x is largely similar to 3.x, but there are some backwards-compatibility breaks, as well as some new features.
Make sure you use the correct PHP version. This library uses the object type-hint and therefore requires PHP 7.2+. The support for HHVM is dropped.
All classes are now using type hinting for method arguments and return types, including the void
return type. This
means if you have extended or implemented one of the library classes in your code, you will have to update the
signatures of your extended/implemented methods to match the new signatures.
For most users this involves only updating classes implementing the ContainerConfigInterface
.
Aura\Di\Injection\InjectionFactory::newInstance()
now requires an instance of Aura\Di\Resolver\Blueprint
to be passed as the parameter, instead of the former classname, parameter array and setter array.
From version 4.x the library will implement the official container standard interface (PSR 11) instead of the container-interop interface.
LazyRequire and LazyInclude could be constructed with a lazy object instead of a filename. This was probably only used for testing purposes (it was not included in any docs) but is included here in case someone is actually using this.
Aura.Di 3.x is largely similar to 2.x, but there are some backwards-compatibility breaks, as well as some new features.
The way the container is instantiated has been changed from this ...
use Aura\Di\Container;
use Aura\Di\Factory;
use Aura\Di\ContainerBuilder;
$di = new Container(new Factory);
// or
$container_builder = new ContainerBuilder();
$di = $container_builder->newInstance(
array(),
array(),
$auto_resolve = false
);
... to this:
use Aura\Di\ContainerBuilder;
$container_builder = new ContainerBuilder();
// use the builder to create and configure a container
// using an array of ContainerConfig classes
$di = $container_builder->newConfiguredInstance([
'Aura\Cli\_Config\Common',
'Aura\Router\_Config\Common',
'Aura\Web\_Config\Common',
]);
Use of $di->setter
in 2.x is now $di->setters
in 3.x. Please note there is an additional s
in the end.
The container now calls lock()
automatically when you call get()
or newInstance()
, so make sure everything is lazy-loaded, or else you will run into something like cannot modify container when locked.
Aura\Di\Config
in 2.x is now Aura\Di\ContainerConfig
in 3.x.
Example taken from Radar:
$di->params['Radar\Adr\Handler\RoutingHandler']['matcher'] = $di->lazyGetCall('radar/adr:router', 'getMatcher');
Here the value assigned to matcher
is taken from the RouterContainer getMatcher()
method.
An instance factory creates multiple instances of the same class; refer the docs for more information.