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