|
| 1 | +Symfony Contracts |
| 2 | +================= |
| 3 | + |
| 4 | +A set of abstractions extracted out of the Symfony components. |
| 5 | + |
| 6 | +Can be used to build on semantics that the Symfony components proved useful - and |
| 7 | +that already have battle tested implementations. |
| 8 | + |
| 9 | +Design Principles |
| 10 | +----------------- |
| 11 | + |
| 12 | + * contracts are split by domain, each into their own sub-namespaces; |
| 13 | + * contracts are small and consistent sets of PHP interfaces, traits, normative |
| 14 | + docblocks and reference test suites when applicable, etc.; |
| 15 | + * all contracts must have a proven implementation to enter this repository; |
| 16 | + * they must be backward compatible with existing Symfony components. |
| 17 | + |
| 18 | +FAQ |
| 19 | +--- |
| 20 | + |
| 21 | +### How to use this package? |
| 22 | + |
| 23 | +The abstractions in this package are useful to achieve loose coupling and |
| 24 | +interoperability. By using the provided interfaces as type hints, you are able |
| 25 | +to reuse any implementations that match their contracts. It could be a Symfony |
| 26 | +component, or another one provided by the PHP community at large. |
| 27 | + |
| 28 | +Depending on their semantics, some interfaces can be combined with autowiring to |
| 29 | +seamlessly inject a service in your classes. |
| 30 | + |
| 31 | +Others might be useful as labeling interfaces, to hint about a specific behavior |
| 32 | +that could be enabled when using autoconfiguration or manual service tagging (or |
| 33 | +any other means provided by your framework.) |
| 34 | + |
| 35 | +### How is this different from PHP-FIG's PSRs? |
| 36 | + |
| 37 | +When applicable, the provided contracts are built on top of PHP-FIG's PSR. We |
| 38 | +encourage relying on them and won't duplicate the effort. Still, the FIG has |
| 39 | +different goals and different processes. Here, we don't need to seek universal |
| 40 | +standards. Instead, we're providing abstractions that are compatible with the |
| 41 | +implementations provided by Symfony. This should actually also contribute |
| 42 | +positively to the PHP-FIG (from which Symfony is a member), by hinting the group |
| 43 | +at some abstractions the PHP world might like to take inspiration from. |
| 44 | + |
| 45 | +### Why isn't this package split into several packages? |
| 46 | + |
| 47 | +Putting all interfaces in one package eases discoverability and dependency |
| 48 | +management. Instead of dealing with a myriad of small packages and the |
| 49 | +corresponding matrix of versions, you just need to deal with one package and one |
| 50 | +version. Also when using IDE autocompletion or just reading the source code, it |
| 51 | +makes it easier to figure out which contracts are provided. |
| 52 | + |
| 53 | +There are two downsides to this approach: you may have unused files in your |
| 54 | +`vendor/` directory, and in the future, it will be impossible to use two |
| 55 | +different sub-namespaces in different major versions of the package. For the |
| 56 | +"unused files" downside, it has no practical consequences: their file sizes are |
| 57 | +very small, and there is no performance overhead at all since they are never |
| 58 | +loaded. For major versions, this package follows the Symfony BC + deprecation |
| 59 | +policies, with an additional restriction to never remove deprecated interfaces. |
| 60 | + |
| 61 | +Resources |
| 62 | +--------- |
| 63 | + |
| 64 | + * [Documentation](https://symfony.com/doc/current/components/contracts.html) |
| 65 | + * [Contributing](https://symfony.com/doc/current/contributing/index.html) |
| 66 | + * [Report issues](https://github.com/symfony/symfony/issues) and |
| 67 | + [send Pull Requests](https://github.com/symfony/symfony/pulls) |
| 68 | + in the [main Symfony repository](https://github.com/symfony/symfony) |
0 commit comments