Download the PHP package pwm/sfw-container without Composer
On this page you can find all versions of the php package pwm/sfw-container. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download pwm/sfw-container
More information about pwm/sfw-container
Files in pwm/sfw-container
Package sfw-container
Short Description A simple Container that ensures a cycle-free dependency graph
License MIT
Homepage https://github.com/pwm/sfw-container
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 sfw-container
SFW Container
A minimalistic DI container with cycle detection, cacheable instance resolution and dynamic loading.
Table of Contents
- Why
- Requirements
- Installation
- Usage
- How it works
- Tests
- Changelog
- Licence
Why
There are many DI containers out there. My design goals were:
- Minimalism
- Cycle detection in the dependency graph
- Instance caching by default
- Dynamic loading
Requirements
PHP 7.1+
Installation
composer require pwm/sfw-containerUsage
Basic usage:
Cycle detection:
Factory vs. cached instances:
Dynamic loading:
How it works
A container is just a map where keys are ids of classes defined by us and values are functions, called resolvers, that know how to instantiate these classes. Resolving a class simply means executing its resolver which will return an instance of the class. It's good practice to use full class names namepsace included as ids but we are free to use any string we like.
All resolvers get the container itself as their first argument which makes it easy to resolve from within a resolver, making the resolution process recursive. This is very useful as classes may have other classes as dependencies.
While we are free to build any dependency graph we like, the resolution process will stop when it encounters a cycle while traversing it. This ensures that only acyclic graphs (ie. DAGs) are handled and saves us from blowing the callstack.
The container caches resolved instances by default meaning that any subsequent resolution will return the same instance. This is good and usually what we want. However, if a resolver was added via the factory() method then every resolution will return a new instance of that class.
We can also pass extra parameters to resolvers. This, combined with factory(), makes it possible to implement dynamic loading, ie. to instantiate an interface in various different ways. An example of this would be what is known as the Strategy pattern, ie. using runtime information, eg. a user supplied CLI parameter, to instantiate the appropriate implementation of some interface.
Tests
$ vendor/bin/phpunit
$ composer phpcs
$ composer phpstan
$ composer infectionChangelog
Click here
Licence
MIT
