TODO
- Make compiler able to be definition-aware for purposes of derived class
information. Basically, allow attaching other Definition objects to a compiler
which it will then consult during compile() in order to flesh out dependency
details. Use case: a concrete DbTable object in a user library. In this case,
currently compiling against that object will provide no supertypes; having the
ability to attach a previously created definition would allow the compiler to
check against those and provide information as it locates it.
- Integrate the EventManager into the Compiler and Code\Scanner in order to
allow attaching listeners to interesting events. Use cases include logging and
debugging during definition compilation.
- Ability to provide both class properties and method-specific parameters via
configuration (which solves disambiguation when multiple methods specify the
same parameter names)
Proposed solution:
array(
'properties' => array(
'Zend\Foo\Bar' => array(
'public' => true,
'methods' => array(
'__construct' => array(
'params' => array(
'foo' => 'bar',
),
'class' => 'Some\Default\Class'
),
'setConfig' => array(
'params' => array(
'bar' => 'baz',
),
),
),
),
),
)
- Ability to pass configuration to a generated ServiceLocator
- Skip optional arguments if not passed in configuration or part of definition
(current behavior is to raise an exception if *any* arguments are missing)
- Scoped Containers:
Described here:
http://picocontainer.org/scopes.html
This is something that should be explored when we start using these containers
with ServiceLocators inside an application. While part of this has to do with
garbage collection in Java (something we need not worry with in PHP since there
is no persistent in-memory objects), the interesting use case would be having a
container cloned from another container that has more or less (a subset) of the
definitions available to the Container's newInstance() and get() facilities.
- Better Strategy Management
Currently, the strategies for determining dependencies is hard coded into the
various definitions. Ideally, we'd be able to have configurable strategies
that the definitions can then utilize to do their job:
http://picocontainer.org/injection.html
We currently support constructor injection and setter injection (methods prefixed
by set[A-Z])
- Annotation Parsing
Ideally, at some point, Zend\Code\Scanner will support Annotation parsing. When
this is possible, we'd like to be able to use @inject similar to
http://picocontainer.org/annotated-method-injection.html
- SuperType Resolution
(partially done inside resolveMethodParameters with is_subtype_of())
If a class claims it needs a dependency of not an object, but a particular
interface, the ability to find an object that suits that dependency, either
through a concept called 'Preferred Objects' or via a 'Property'. The
following should be supported:
The compiler also needs to be aware of other definitions when looking up SuperTypes
$definition = new AggregateDefinition();
$definition->addDefinition('Zend\Controller\DiDefinition');
$compiler = new Compiler()
$compiler->addDefinition($definition);
$compiler->addCodeScanner(__DIR__ . 'My/Blog');
$array = $compiler->compile()
$definition->addDefinition(new ArrayDefinition($array));
- Performance & Benchmarking
Zend\Code\Scanner- check memory usage, perhaps use gc_collect_cycles() to free memory,
we'll have to do this on large scan bases.
Benchmark compiler: reflection vs. code scanner