Download the PHP package ice-cream/di without Composer
On this page you can find all versions of the php package ice-cream/di. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package di
Short Description ice-cream di (Dependency Injection) is my own take on DI, to keep it simple and easy to use.
License MIT
Homepage http://adambalan.com/
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package di
Ice Cream DI
[
]()
[
]()
- Requires PHP 7.2.x
- Is Standalone
I wanted a simple and effective way to replicate pimple and create DI at it's most basic level.
The core concept is simple, you have a container that you can add items to and fetch via the ArrayAccess interface.
We also allow you to create factories, which allow you to return new instances of the object each time instead of the same object every time.
Documentation
You can view this packages documentation here
Philosophy
Ice Cream is not meant to be the next big thing in OSS. It is essentially Pimple plagiarized.
I wanted to build a simple DI container that I could use in my own projects to try and better understand DI at a fundamental level.
Examples:
The following is a super basic example of how to use the container.
ATTN!!
We pass the instance of the container to all of our closures, this is exactly like pimple. Even when it comes to extending the already registered service provider you can be sure that the new extension will also have the container object.
Even more simpler:
ATTN!
Should you have something in the container with the same name and you throw in another object under the same name you will break your container. Make sure your names are unique.
ATTN!
You cannot manipulate a container object after its been called, for example:
The above will error out, because when you "build" the item from the service container, we lock it in place.
What if you want to extend an already registered item in the container? Well we can do the following:
This allows you to easily register and then manipulate items in the container.
If you just want the closure back, you can call the raw method:
When you call the factory method, you will always get a new instance of the registered object. For instance:
Where as with the the regular $container['service'] you will always get the same object back.
What if you have a factory that has dependencies? For example, assume you have a class that each time it's called,
you need to inject dependencies into the class. You can use the resolveFactory method:
As you see above we inject the dependencies. We even add on an addition dependency which is the $c container object
dependency so that the registered factory that will be resolved has a instance of the container.
We can also call a method on a container object:
