PHP Classes

File: vendor/container-interop/container-interop/README.md

Recommend this page to a friend!
  Classes of uche   Farm Price   vendor/container-interop/container-interop/README.md   Download  
File: vendor/container-interop/container-interop/README.md
Role: Documentation
Content type: text/markdown
Description: Documentation
Class: Farm Price
API to get the prices from agriculture markets
Author: By
Last change:
Date: 2 years ago
Size: 8,725 bytes
 

Contents

Class file image Download

Container Interoperability

Latest Stable Version Total Downloads

Deprecation warning!

Starting Feb. 13th 2017, container-interop is officially deprecated in favor of PSR-11. Container-interop has been the test-bed of PSR-11. From v1.2, container-interop directly extends PSR-11 interfaces. Therefore, all containers implementing container-interop are now de-facto compatible with PSR-11.

  • Projects implementing container-interop interfaces are encouraged to directly implement PSR-11 interfaces instead.
  • Projects consuming container-interop interfaces are very strongly encouraged to directly type-hint on PSR-11 interfaces, in order to be compatible with PSR-11 containers that are not compatible with container-interop.

Regarding the delegate lookup feature, that is present in container-interop and not in PSR-11, the feature is actually a design pattern. It is therefore not deprecated. Documentation regarding this design pattern will be migrated from this repository into a separate website in the future.

About

container-interop tries to identify and standardize features in container objects (service locators, dependency injection containers, etc.) to achieve interoperability.

Through discussions and trials, we try to create a standard, made of common interfaces but also recommendations.

If PHP projects that provide container implementations begin to adopt these common standards, then PHP applications and projects that use containers can depend on the common interfaces instead of specific implementations. This facilitates a high-level of interoperability and flexibility that allows users to consume any container implementation that can be adapted to these interfaces.

The work done in this project is not officially endorsed by the PHP-FIG, but it is being worked on by members of PHP-FIG and other good developers. We adhere to the spirit and ideals of PHP-FIG, and hope this project will pave the way for one or more future PSRs.

Installation

You can install this package through Composer:

composer require container-interop/container-interop

The packages adheres to the SemVer specification, and there will be full backward compatibility between minor versions.

Standards

Available

Proposed

View open request for comments

Compatible projects

Projects implementing ContainerInterface

Projects implementing the delegate lookup feature

Middlewares implementing ContainerInterface

Projects using ContainerInterface

The list below contains only a sample of all the projects consuming ContainerInterface. For a more complete list have a look here.

| | Downloads | | --- | --- | | Adroit | ![](https://img.shields.io/packagist/dt/bitexpert/adroit.svg) | | Behat | ![](https://img.shields.io/packagist/dt/behat/behat.svg) | | blast-facades: Minimize complexity and represent dependencies as facades. | ![](https://img.shields.io/packagist/dt/blast/facades.svg) | | interop.silex.di: an extension to Silex that adds support for any container-interop compatible container | ![](https://img.shields.io/packagist/dt/mouf/interop.silex.di.svg) | | mindplay/walkway: a modular request router | ![](https://img.shields.io/packagist/dt/mindplay/walkway.svg) | | mindplay/middleman: minimalist PSR-7 middleware dispatcher | ![](https://img.shields.io/packagist/dt/mindplay/middleman.svg) | | PHP-DI/Invoker: extensible and configurable invoker/dispatcher | ![](https://img.shields.io/packagist/dt/php-di/invoker.svg) | | Prophiler | ![](https://img.shields.io/packagist/dt/fabfuel/prophiler.svg) | | Silly: CLI micro-framework | ![](https://img.shields.io/packagist/dt/mnapoli/silly.svg) | | Slim v3 | ![](https://img.shields.io/packagist/dt/slim/slim.svg) | | Splash | ![](https://img.shields.io/packagist/dt/mouf/mvc.splash-common.svg) | | Woohoo Labs. Harmony: a flexible micro-framework | ![](https://img.shields.io/packagist/dt/woohoolabs/harmony.svg) | | zend-expressive | ![](https://img.shields.io/packagist/dt/zendframework/zend-expressive.svg) |

Workflow

Everyone is welcome to join and contribute.

The general workflow looks like this:

  1. Someone opens a discussion (GitHub issue) to suggest an interface
  2. Feedback is gathered
  3. The interface is added to a development branch
  4. We release alpha versions so that the interface can be experimented with
  5. Discussions and edits ensue until the interface is deemed stable by a general consensus
  6. A new minor version of the package is released

We try to not break BC by creating new interfaces instead of editing existing ones.

While we currently work on interfaces, we are open to anything that might help towards interoperability, may that be code, best practices, etc.