Allow injection of any container object as factory parameter via type hinting

[jdreesen]

With this PR it's possible to inject any container object into a factory via type hinting (see #197).

This means that instead of fetching the needed objects from the container inside your factory like this

factory(function(ContainerInterface $c) {
  return new Thing($c->get(Service::class));
});

you can now let the container inject your dependencies as arguments to your factory directly

factory(function(Service $s) {
  return new Thing($s);
});

This works with multiple arguments, too, of course. And it's backwards compatible, so if you don't type hint the first parameter, an instance of the ContainerInterface will be injected (but that's not recommended anyway).

There was a discussion about "angular style DI" in #197 and #239 but as I wasn't sure what's the best way to define this type of dependencies this feature was left out here.

I did a quick benchmark (my first one using blackfire) with the provided blackfire run --samples=100 php factory.php which showed a performance decrease of about 10% but I'm not sure how reliable this is for real world situations. Maybe you have better ways for benchmarking this?

Todo:

• documentation
• changelog

[jdreesen]

Added documentation and entry in the changelog.

[mnapoli]

Looks absolutely awesome! I need to test regarding performances too (I have a half-done repository with a few performance tests, I need to finish it a push it sometime soon) but if it's only 10% that seems very good considering how useful it will be.

I'll probably can't review and merge this week, but hopefully I'll have time to look at it soon :)

[mnapoli]

Hi, just an update: I moved house and don't have internet access yet, it will be like that for another week, sorry for the delay ;)

[mnapoli]

Getting back to this, sorry for the delay. I tried it out today performance-wise. Form the very simple benchmark it shows a 16% slowdown when using factory(): https://blackfire.io/profiles/compare/974a4ada-38aa-472f-97bd-bf5c3220c1bf/graph And that's just the total time: for the FactoryDefinitionResolver, the time spent there is up by 40%.

It's bother me a little bit even though I really want this feature in. Using closures as factories is a main feature, and when you compare it straight to (for example) Pimple it will be much slower. Maybe there is a little bit of room for improvements to find.

One thing I was looking into lately is caching reflection almost entirely. It's a bit of work and I haven't pushed it on GitHub yet, if you are interested to have a look let me know. Also I have no guarantee at all that it will bring improvements.

[jdreesen]

I understand your concerns. Your reflection caching work sounds interesting. Maybe we should wait with this PR until it moved further.

[mnapoli]

FYI this PR is included in #347, ready to be merged in master for 5.2 (if you have any comment on #347 feel free)