Lately, I’ve been playing quite a lot with the notion of container definition interoperability.
Container definition interoperability? Why?
The problem we are trying to solve is the problem of packages interoperability between frameworks. Have a look at this packagist search for the "Glide" library.
See? There is the code for Glide, and then, there are a million of small libraries that provide Glide services for each framework out there (laravel-glide, glide-symfony, yii2-glide, cakephp-glide, lumen-glide...) It doesn't make any sense! Package writers are loosing precious time writing spaghetti code for each framework out there. This needs to be fixed.
But each framework out there has its own format (or uses PHP directly), so it will be hard to have everybody agree on a single file format for services, right?
That's why we are proposing a common set of interfaces that describe a container entry.
The final goal is the ability for any PHP package (on Composer) to provide the container of your application with a set a container definitions. The container of your application can then take these definitions and turn them into actual container entries.
You can have a look at the proposed interfaces on the definition-interop project (work in progress)
Objects implementing the definition-interop interfaces are meant to be consumed by a container (or even better, by a compiler that generates an optimized container).
Actually, in definition-interop, containers are consuming definition providers which are objects providing a set of definitions.
Wanna have a look at a definition provider written in pure PHP? Have a look at this provide for the Glide library. It is written using the Assembly library that provides definitions implementing definition-interop.
But I don't want to describe my definitions using PHP... I want JSON/YAML or XML definition files!
Keep cool! That's not an issue! You don't have to use Assembly to write your definitions. Assembly is only one possible library implementing definition-interop. Actually, definitions could come from everywhere, in any format. They could be stored in a file, in a cache, in database... It's up to your imagination.
The most likely source of definitions will be service files (like YML files, JSON files, ...) So package writers can choose between any format they like, and pick the appropriate "loader" that will transform their configuration file into a set of definition objects.
As a matter of facts, there is already one loader available for definition-interop: a YML loader that accepts a format very similar to Symfony services YML files. You can have a look at the YML loader here.
Discovery... you said "discovery"?
Package writers must be able to provide a DefinitionProvider to the container.
On the other end, the container must be able to consume DefinitionProviders.
Actually, there is a cool PHP tool out there that specializes in resources discovery. Its name is Puli. Using Puli, a package can provide (i.e. publish) a class (or a file). These classes can be consumed by containers.
So the idea is simple: packages providing DefinitionProvider (i.e. mostly loaders) can provide this definition provider to Puli. And containers will consume those definition providers. Actually, it is just slightly more difficult. DefinitionProviders are instances of objects implementing the DefinitionProviderInterface. But in its current version, Puli can only provide classes, not instances. So Puli will instead provide a factory that can create a definition provider using a static method. The factory must of course implement a DefinitionProviderFactory interface.
See? A container factory can use Puli to discover all definition provider factories. Using those factories, it can get all definition providers, add them to the container it is building and return the container. Also, please note how Puli's usage is restricted to factories. Containers and definition providers know nothing about Puli. So if some day a more shiny discovery library comes out there, there are no strong ties between definition-interop and Puli. Only the factories need to be refactored.
But wait, it's not over yet, it gets even better! Loaders can use Puli (if they want) to discover the definition files in packages. For instance, the YAML loader can discover YML files in packages declaring YML service files.
