DI containers usage comparison

DI containers summary.md

DI containers usage comparison

DI containers are sorted alphabetically.

• Aura DI: source
• Auryn: source
• AWS/Guzzle: source
• Laravel 4: source
• League\Di: source
• Mouf: source
• Orno\Di: source
• PHP-DI: source
• Pimple: source
• PPI: source
• Symfony 2: source
• Zend Framework 2: source

Submit PR to expand.

Comparison:

Container	Read	Test	Not found behavior	ArrayAccess
Aura DI	get($key)	has($key)	Exception	No
Auryn	make($key, [$params])		Exception	No
AWS/Guzzle	get($key, [$throwAway])	array access	Exception	Yes
Laravel	make($key, [$params])	bound($key)	Exception?	Yes
League\Di	resolve($key)	bound($key)	Exception	No
Mouf	get($key)	has($key)	Exception	No
Orno\Di	resolve($key, [$args])		?	No
PHP-DI	get($key)	has($key)	Exception	No
Pimple	array access	array access	Exception	Yes
PPI	get($key, [$bool])	hasOption($key)	Exception	Yes
Symfony	get($id, [$invalidBehavior])	has($key)	Null or Exception	No
ZF2	get($key, [$params])		Null	No

Parameters surrounded by [] (like get($key, [$param])) are optional parameters.

Summary

• Read method name:
  • get: 7
  • make: 2
  • resolve: 2
  • array access: 1
• Read mandatory number of parameters is always 1
• Test existence:
  • with: 9
  • without: 4
• Test existence method name:
  • has: 4
  • bound: 2
  • hasOption: 1
  • array access: 2
• Not found behavior:
  • exception: 10
  • null: 2
• ArrayAccess:
  • no: 8
  • yes: 4

To get a binding from League\Di you actually use resolve($key). The build($className) is a public method to automatically build an object, resolving any of it's dependencies from the container. The item $className doesn't even need to be registered, and it can still build it.

All items bound within the container are either a Closure or an instance of League\Definition. When calling resolve($key) on an item that is a Closure, it simply get's executed and returns the results. If the requested $key is an instance of League\Definition, it runs the magic __invoke() method from that instance, and there it builds the object by getting the constructor params and building each dependency as needed, resolving it from the parent container if available.

So, to sum it up, you should change the League\Di entry for the Read column from build to resolve.

@jeremeamia no PRs on gists...

@mnapoli can you differentiate Zend\Di and Zend\ServiceManager? Anyway, the zf2 containers throw exceptions on not-found and have a has($key) method. get($key, [$params]) is only for Zend\Di

Here is my fork. Added Mouf:
https://gist.github.com/moufmouf/6163791
https://gist.github.com/moufmouf/6163791/revisions

Actually, I just added aliases for "get" and "has" in Mouf's DIC, since it seems to be so common.

@jeremeamia: thanks, merged (manually)

@dongilbert: thanks, edited

@moufmouf: thanks, merged

@Ocramius: What's the difference between them? I have nothing against it except counting the same thing twice, so is there (out of those 2) only one that we should consider maybe?

what does arrayaccess mean?

It means that the container class implements the ArrayAccess interface. So while there may not be a method for get or has, you can accomplish those functions by accessing the class as an array.

https://github.com/granula/inversion might be quite interesting addon to mentioned modules.

How exactly you came has() being the common name for:

can return an entry for the given identifier

Especially since only 4 out of 9 actually even had a method with such name and (from the surface-scan) it looks like at least two are just checking whether they have configuration for such instance. And the rest are checking whether they have already created such instance.

Neither of those sound like checking, if container "can create". Hell .. I am not even sure how you could check it beforehand.