--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/3e454eb9-5088-40fb-b280-1d82725b512c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6KTyb3pYaA0LizsFWfrb-zgASAk0kPDJ_b-3%3DoveEdYjQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/41A79104-E56E-4E11-9691-E3D342A9199E%40gmail.com.
Hello PSR-18 WG,
According to our Naming Conventions bylaw, section 1: Interfaces MUST be suffixed by "Interface".
I know that this style has been contested before, but we have an established convention in place, so we should stick to it.Anyone who doesn't like this can circumvent it via import aliases (which I do all the time, by the way).
On a different, opinionated, note, I don't particularly like the main method signature: public function sendRequest(RequestInterface $request): ResponseInterface;The resulting consumer code would look like:$client->sendRequest($request);which IMHO is redundant and harder to read; I would much more prefer just:$client->send($request);The parameter is explicitly typed already, so I don't think that the additional hint to "Request" is needed in the name of the method.
This is obviously a small detail, and it can probably be argued either way; IIRC it has even been discussed already within the WG, but there are no references in the metadoc, so I'd like the WG to either rename the method or add some sound reasoning to the metadoc about the current, more verbose, name.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1tOnNsEp6JajY-mEcef4TmWP0zRDnWHmoYYkMWj5eY5NQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Can we have some news about the review process and possibly the acceptance vote? I don't want to rush anybody but...
My team is really impatient to replace our own interface by the PSR-18 one for a library that needs a HttpClient instance to work.
It's the only remaining dependency that doesn't use a PSR interface (thanks to PSR-3, 6, 7, 11, 16 and 17 ... quite a lot).
I am curious why the RequestExceptionInterface does not also include a getResponse method. Unless I am missing something (or likely some conversation elsewhere) it seems that if the request failed after connecting with a server that there would be a response.
A Client MUST throw an instance ofPsr\Http\Client\ClientExceptionInterface
if and only if it is unable to send the HTTP request at all or if the HTTP response could not be parsed into a PSR-7 response object.If a request cannot be sent because the request message is not a well-formed HTTP request or is missing some critical piece of information (such as a Host or Method), the Client MUST throw an instance of
Psr\Http\Client\RequestExceptionInterface
.