Add message factories

[sagikazarmark]

Factory implementations for PSR-7 related objects.

It adds one external dependency (which becomes stable this week). It provides Factory interfaces.

The idea behind this project is that message construction COULD also be standardized. It's not a requirement, but can be useful in some cases. Actually it is useful in any cases where you allow using any kind of PSR-7 implementation, not just one.

We regularly use it in HTTPlug and any packages which rely on it: FOS HTTP Cache, FXMLRPC, possibly in the future Geocoder too.

We had these interfaces implemented in a custom repository along with factories for Diactoros, but we realized that it would be cool if factories were provided by implementations themselves. In case of Diactoros it is possibly harder, because it already provides some factories which are incompatible with these interfaces. In such cases we have to use bridge packages, like this:

https://github.com/mekras/httplug-diactoros-bridge

However it adds an extra dependency, and somewhat redundancy, as you require a message implementation AND a bridge package for it.

Not sure if it is something that you want to merge, but I thought I would submit it anyway.

/cc @dbu @joelwurtz @mekras

[jeskew]

I'm -1 on taking on a new external dependency, especially if it's just to provide built-in integration with a different third-party library. I think keeping the proposed change in a repository that depends on this package is a better solution.

[dbu]

the aim of php-http is not to be any third-party library but the common standard for creating messages and abstracting from specific clients. it should eventually be turned into a PSR.

but i can see that we are too early to be sure whether this will work out.

[mtdowling]

Agreed with @jeskew. In it's current state, I see this as an integration that should be made in the third-party library and not in Guzzle. If this ever becomes a PSR, we can look at integrating support in this repo.

[sagikazarmark]

Hey Jonathan, I see your point, so let me try better explaining this proposal. This is not trying to be a third party integration, quite the opposite. These interfaces allow to integrate this library into many other, so from this point of view this library is the third party. Interfaces cannot have constructors by nature. Unlike other PSRs, this one defines value objects (sort of). It means that they are created and filled with data by your code, which requires you to know about the implementation. It is not really interoperable. That's why we created these factory interfaces. While we hope we can make these some kind of standard, message factories can't really be made a PSR. Mentioning HTTPlug was probably a mistake: this has nothing to do with it. HTTPlug indeed uses these interfaces, but the purpose of them is not to provide integration for it. I think FOS HTTP Cache is a good demonstration: while it uses HTTPlug under the hood, it is irrelevant. The package itself needs to create message objects (requests actually). They have two options: Stick to one PSR-7 implementation OR Rely on purely the interfaces and dependency injection. Which do you think is better? Which is more interoperable? And this is only one example, but can be applied to any packages working with PSR-7.