Related tickets:
- Class
- Factory
- Value
- Alias
<?php | |
trait class ABetterNameHere | |
{ | |
public function someGenericMethod() | |
{ | |
// ... | |
} | |
} |
Related tickets:
<?php | |
$mock = SimpleMock::mock('My\Class', array( | |
'getBar' => 'hello', | |
'doSomething' => function ($param) { | |
echo 'foo'; | |
}, | |
)); | |
// Same as |
Materiel:
<?php | |
interface Cache | |
{ | |
public function get($id); | |
public function set($id, $value); | |
} |
<?php | |
$factory = function () { | |
return new Foo(); | |
} | |
$factory = function () use ($factory) { | |
$object = $factory(); | |
$object->setOption('Hello'); |
<?php | |
use ...; | |
class GeneratingArgumentsTest extends \PHPUnit_Framework_TestCase | |
{ | |
/** | |
* @var VariableArgumentCollectionFactory | |
* @Inject | |
*/ |
Dans la v4 on déclare un objet avec DI\object()
. Automatiquement ça va étendre toute précédente définition, par exemple si on a plusieurs fichiers de config, mais surtout pour l'autowiring (ou les annotations si elles sont utilisées).
Du coup avec DI\object()->constructorParameter('paramName', 'the value')
on peut "compléter" la définition autowiring sans avoir à redéclarer tous les paramètres qui sont déjà automatiquement résolus avec les type-hints.
Dans la v5 il y'aura beaucoup plus de fonctionnalités orientées au applications modulaires, donc avec plein de fichiers de config qui peuvent se surcharger, etc. (comme les bundles Symfony)
interface MoneyStorage {
}
class BankAccount implements MoneyStorage {
public function __construct(Logger $logger, $account) ...
}
return [