Extract Response factory from Message factory

[sagikazarmark]

No description provided.

[dbu]

i only read the discussion on slack now. but i think i agree that if we should split, we should aim for more consistency.

i think a client library is likely to only need to create requests, but never responses. creating the response is the job of the Httplug implementation/adapter. if i could typehint RequestFactory, it would be clear that i only want to create requests, never build responses from something. to me the consistent thing would be RequestFactory, ResponseFactory and a MessageFactory that can do both.

i know that this is inverse to the PSR-7 request and response, where message is the common base. i think for creating them, the common thing needs to be the union rather than a subset. the factories share no common methods as far as i can see.

[sagikazarmark]

i think a client library is likely to only need to create requests, but never responses

I don't think this is true. For example in case of SocketClient, the client creates responses from plain data. Any adapter, with an underlying client which is not PSR-7 compliant will return a response which must be transformed into a PSR-7 response...using a message factory.

And one last thought here: if you typehint for RequestFactory, you won't be able to create responses as you can't expect that it is a response factory or not. This is a bit similar to the case with async and not async.

RequestFactory, ResponseFactory and a MessageFactory that can do both

This would imply that you could create RequestFactories as well. Do you really want that?

i know that this is inverse to the PSR-7 request and response

Actually I don't think this is a problem.

[dbu]

sorry, i formulated that unclear. by "client library" i am thinking of a generic library that uses a Httplug implementation and the request factory to send requests. not client in the sense of HTTP.

with libraries that provide some functionality on top of Httplug, like FOSHttpCache for example, we only need to create requests, never responses (except maybe in tests but then we could mock the interface)

[sagikazarmark]

Ah, I see. Makes sense.

That still leaves the question open: do we actually want to implement RequestFactory objects separately? Currently I implemented a ResponseFactoryTrait which is not usable on its own, but can be used with Server Message and plain Message factories.

[dbu]

i don't think we should implement them separately, but somebody might
want to.
but more important, i think a library should be able to typehint it
separately, for code readability.

[sagikazarmark]

Ok, I think that is not a big deal. The typehinting thing actually makes sense.

[sagikazarmark]

@dbu I think this is ready.