container-interop / fig-standards

Standards either proposed or approved by the Framework Interop Group

Container Interoperability

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

• ContainerInterface. Description Meta Document. Describes the interface of a container that exposes methods to read its entries.
• Delegate lookup feature. Meta Document. Describes the ability for a container to delegate the lookup of its dependencies to a third-party container. This feature lets several containers work together in a single application.

Proposed

View open request for comments

Compatible projects

Projects implementing ContainerInterface

• Acclimate: Adapters for Aura.Di, Laravel, Nette DI, Pimple, Symfony DI, ZF2 Service manager, ZF2 Dependency injection and any container using ArrayAccess
• Aura.Di
• auryn-container-interop
• Burlap
• Chernozem
• Data Manager
• Disco
• InDI
• League/Container
• Mouf
• Njasm Container
• PHP-DI
• Picotainer
• PimpleInterop
• Pimple3-ContainerInterop (using Pimple v3)
• SitePoint Container
• Thruster Container (PHP7 only)
• Ultra-Lite Container
• Unbox
• XStatic
• Zend\ServiceManager
• Zit

Projects implementing the delegate lookup feature

• Aura.Di
• Burlap
• Chernozem
• InDI
• League/Container
• Mouf
• Picotainer
• PHP-DI
• PimpleInterop
• Ultra-Lite Container

Middlewares implementing ContainerInterface

• Alias-Container: add aliases support to any container
• Prefixer-Container: dynamically prefix identifiers
• Lazy-Container: lazy services

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
Behat
blast-facades: Minimize complexity and represent dependencies as facades.
interop.silex.di: an extension to Silex that adds support for any container-interop compatible container
mindplay/walkway: a modular request router
mindplay/middleman: minimalist PSR-7 middleware dispatcher
PHP-DI/Invoker: extensible and configurable invoker/dispatcher
Prophiler
Silly: CLI micro-framework
Slim v3
Splash
Woohoo Labs. Harmony: a flexible micro-framework
zend-expressive

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.

fig-standards's Issues

This repo clone is outdated and should be removed (or updated)

The PHPFIG website points to this repo as the source for the PSR-11 container proposal. Problem is: The proposal is accepted now, without the delegate feature. See http://www.php-fig.org/psr/ under section "review".

This leads to confusion about the current state of this standard recommendation. If PHPFIG updates their site, the link would be gone anyway, but every little bit helps.

Poll: needed features

Now that we listed all possible features we could think of, let's rank these features!

Here is my personal take on it. I'm opening this issue so we can discuss on it. Maybe we can summarize this in the META or in a GIST later. If you have a better idea, let me know.

Feature	Rating	Comment
Ability to create a container entry using the new keyword.	++
Ability to call methods (setters or otherwise) on a container entry	++
Ability to set public properties of a container entry.	+	Although setting public properties directly is not the best practice, I feel it is important that containers we write can adapt to such things.
Ability to set private and protected properties of a container entry.	--	I feel this should be highly discouraged. I don't care if some containers out there allow it, but forcing all containers implementing this standard to be able to bypass protected/private modifiers feels plainly wrong
Ability to create a container entry using a static factory method.	+
Ability to create a container entry using a factory method from a container service.	++
Ability to create a container entry using a closure	/
Ability to compile all container entries into a single container for maximum performance.	+
Ability to alias a container entry to another.	++
Ability to modify an entry defined outside of the "module" before it is returned by the container.	++
Ability to create container entries for scalar values.	++
Ability to create container entries from constants (from the define keyword or the const keyword)	+
Ability to create container entries that are numerically indexed arrays. Values of the array can be any valid container entry (i.e. objects, scalars, another array...)	++
Ability to create container entries that are associative arrays (maps). Values of the array can be any valid container entry (i.e. objects, scalars, another array...)	++
Ability for a package to extend those arrays (add elements to the arrays).	++
Ability for a package to manage priority in those arrays	+
Ability to locally declare "anonymous"/"private" services in a package.	+
Ability to provide a default service that should be used when binding an interface.	-	I don't think a package should be allowed to provide a "default" implementation of an interface, as there could be conflicts between packages providing default implementations for the same interface. This should be something decided by the application, not the packages.
Ability to declare "lazy" services (services that are wrapped into proxy objects and instanciated only when needed)	/	Very specific feature. Can be achieved by using factories. I'm not sure it deserves a "special treatment"
Ability to have several services for the same class or interface (for instance, several services implementing a LoggerInterface).	++
Ability to declare if the service should be instantiated once and reused (singleton) or if the service should be instantiated every time it is injected or fetched from the container.	-	I believe two successive calls from a container on a given ID should ALWAYS return the same service. If people need factories, they can use the container to retrieve a factory, and then use the factory to get new instances of the object they want. I feel we should not melt containers and factories. They are different beasts.
Ability to have "optional" references	+
Ability to have fall-back aliases/services: a alias/service is only declared by a package if no other package has provided that service so far.	/
Ability to have static tools analyzing the bindings (for instance, having Packagist analyze the bindings to search for some services...)	+	I'm definitely very keen on this feature (would rate it +++), but I understand this can be a problem for "closure-based" solutions, so I only rated it "+"
Ability to have static tools help us edit the binding. For instance, a dedicated UI that can be used to create services and drag'n'drop services together (like Mouf does)	+	I'm definitely very very keen on this feature (would rate it ++++), but I understand this can be a problem for anything that is not a configuration file based solution, so I only rated it "+"
Ability to perform simple computations on values before injecting them in a container entry	+

Everybody wanting to give a rating is welcome!

Send PR to php-fig

The repo owners here should make a PR against PHP-FIG for the container.md and container-meta.md documents, so they can be available for common review, etc.