[Feature] Disco should be able to autowire bean instances

[shochdoerfer]

As discussed with @Ocramius today it would make sense for Disco to be able to support autowiring for bean instances to reduce the amount of configuration code needed and to be able to get rid of traits for structuring the configuration code.

The following configuration:

/** @Bean */
protected function database() : Database
{
    return new Database('mysql://user:secret@localhost/mydb');
}

/** @Bean */
public function productService() : ProductService
{
    return new ProductService($this->database());
}

could then be simplified like this:

/** @Bean */
protected function database() : Database
{
    return new Database('mysql://user:secret@localhost/mydb');
}

/** @Bean */
abstract public function productService() : ProductService;

At a later stage we could move the methods into separate interfaces - to be able to get rid of the abstract keyword and ultimately get rid of the trait approach.

A few problems need to be solved:

• [ ] When using interfaces as configuration source, how to cope with method naming clashes?
• [ ] When there are multiple database instances available how would Disco decide which one to use? We would need a way to pass the method name or alias name to the bean configuration of the ProductService.
• [ ] For Constructor Injection things are simple, but to be able to decide which methods needs to be called for Setter Injection we might need annotations on the setter methods of the class. So far the goal of Disco was to keep annotations just in the configuration class. Maybe we can solve this differently?
• [ ] How to cope with primitive values that should be injected? Maybe we could rely on the same naming scheme - e.g. when the parameter of the bean definition method is called $dsn we check if the class has a parameter with that name as constructor argument, same for the setter methods.
• [ ] For primitives we obviously need to skip the whole injection logic.
• [ ] When adding this feature it might make sense to enable the production autoloader of Proxy Manager by default as the constant parsing could slow things down quite a bit.

[shochdoerfer]

Just a quick thought: As for primitive value injection we could potentially do some name matching with the parameters injected to the bean configuration method.

[Ocramius]

Didn't have much time to work on this, but I'm currently building Roave/DependencyResolver (currently private).

The idea is to have following:

1. analyze existing code
2. build complete dependency graph (find constructors, setters, etc)
3. run "compiler passes" on the dependency graph (allows replacing dependencies, providing dependencies for when none could be resolved, etc)
4. select dependencies (we don't need everything)
5. run further compiler passes to define which ones are consumer-exposed dependencies, and which ones are just private dependencies (services to never be exposed by the container directly)
6. generate factory code (container-specific, in this case - this is not part of Roave/DependencyResolver)

What you'd do is probably expose a CLI script to generate factory snippets to be copied in the container. What you will get from Roave/DependencyResolver is a framework-agnostic dependency graph that you can traverse and modify.

[shochdoerfer]

Instead of sprinkling annotations in the whole code base to configure setter injection, named injection etc. we could simply add those annotations to the bean configuration method.