2121c55b02
* 5.0: [VarDumper] fix typo Fix support for PHP8 union types [FrameworkBundle] preserve dots in query-string when redirecting [3.4] Fix support for PHP8 union types [PhpUnitBridge] Streamline ansi/no-ansi of composer according to phpunit --colors option [3.4] Small update in our internal terminology [Cache] fix compat with DBAL v3 [HttpClient] Convert CurlHttpClient::handlePush() to instance method [VarDumper] Fix CliDumper coloration [DI] tighten detection of local dirs to prevent false positives [FrameworkBundle] preserve dots in query-string when redirecting Fix precendence in 4.4 bumped Symfony version to 3.4.43 updated VERSION for 3.4.42 update CONTRIBUTORS for 3.4.42 updated CHANGELOG for 3.4.42 |
||
|---|---|---|
| .. | ||
| Cache | ||
| Deprecation | ||
| EventDispatcher | ||
| HttpClient | ||
| Service | ||
| Tests | ||
| Translation | ||
| .gitignore | ||
| CHANGELOG.md | ||
| composer.json | ||
| LICENSE | ||
| phpunit.xml.dist | ||
| README.md | ||
Symfony Contracts
A set of abstractions extracted out of the Symfony components.
Can be used to build on semantics that the Symfony components proved useful - and that already have battle tested implementations.
Design Principles
- contracts are split by domain, each into their own sub-namespaces;
- contracts are small and consistent sets of PHP interfaces, traits, normative docblocks and reference test suites when applicable, ...;
- all contracts must have a proven implementation to enter this repository;
- they must be backward compatible with existing Symfony components.
Packages that implement specific contracts should list them in the "provide"
section of their "composer.json" file, using the symfony/*-implementation
convention (e.g. "provide": { "symfony/cache-implementation": "1.0" }).
FAQ
How to use this package?
The abstractions in this package are useful to achieve loose coupling and interoperability. By using the provided interfaces as type hints, you are able to reuse any implementations that match their contracts. It could be a Symfony component, or another one provided by the PHP community at large.
Depending on their semantics, some interfaces can be combined with autowiring to seamlessly inject a service in your classes.
Others might be useful as labeling interfaces, to hint about a specific behavior that could be enabled when using autoconfiguration or manual service tagging (or any other means provided by your framework.)
How is this different from PHP-FIG's PSRs?
When applicable, the provided contracts are built on top of PHP-FIG's PSRs. But the group has different goals and different processes. Here, we're focusing on providing abstractions that are useful on their own while still compatible with implementations provided by Symfony. Although not the main target, we hope that the declared contracts will directly or indirectly contribute to the PHP-FIG.