Skip to content

Adding PSR package #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Jul 30, 2018
Merged

Adding PSR package #128

merged 13 commits into from
Jul 30, 2018

Conversation

Nyholm
Copy link
Member

@Nyholm Nyholm commented Aug 18, 2017

Yes, This PR is very premature. I just want to make sure we all agree (and look forward to) that this is eventually going to be merged.

This will fix #51

@@ -23,5 +23,5 @@
*
* @throws \Exception If processing the request is impossible (eg. bad configuration).
*/
public function sendAsyncRequest(RequestInterface $request);
public function sendAsyncRequest(RequestInterface $request): Promise;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this problem when we are doing the same update for the Async HTTP client PSR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there needs to be a new major version anyways when a promise PSR is out, so we might as well do this change now to make it more explicit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to be more permissive in the async implementation, to allow every value and exception in our promise, this would be better, after years of use it was a mistake to reduce the scope IMO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair, so what do you suggest? I've written Promise here, not HttpPromise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, it's in another package, we would need to update the promise lib and then allow 2.0 here, but maybe it will not be bc break for this package, so nothing to change here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(We would still need to release a 2.1 with the package dependency upgrade to allow 1.0 || 2.0 for the promise lib)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact what do you think of using https://amphp.org/amp/promises/ interface ? there is an adapter for react and we could drop support of async for guzzle (as it's not really async in fact, it's only parallel)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.. Im not sure at all...

On one hand: Do as little change as possible. That will make it easier for everyone.
On the other hand: Can we make the "correct" decision now so there is no need for v3 when we got a PSR for Promise...? Probably not, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how soon is a PSR Promise to be expected? i would assume that will take a couple of years, so if its a clear and good upgrade, i would be ok to have version 2 do something different. then again, to make the PSR move for sync http client as smooth as possible, its maybe better to not limit ourselves here and avoid a BC break

@@ -42,7 +42,7 @@ public function __construct(
*
* @return ResponseInterface
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in our projects we started the rule that when @return just repeats the return type declaration and has no valuable information, we remove the @return line.

(in that vein "Returns the response" is redundant to the method name. either there is more details to explain or there should be no comment...)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. 👍

I will remove these redundant comments.

* @return ResponseInterface
*/
public function getResponse()
public function getResponse(): ResponseInterface
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a BC break: https://3v4l.org/LOOiv

Is this something we want to avoid in this update to make it as smooth as possible?

*/
public static function create(
RequestInterface $request,
ResponseInterface $response,
\Exception $previous = null
) {
): self {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@Nyholm
Copy link
Member Author

Nyholm commented Jul 29, 2018

Im done with this PR. I suggest merging it now and start prepare for a 2.0 release.

Releasing 2.0 is obviously blocked by a stable release of psr/http-client

@Nyholm
Copy link
Member Author

Nyholm commented Jul 29, 2018

I removed HHVM because it failed because of a PHPSpec error (I think) https://travis-ci.org/php-http/httplug/jobs/409431649

Copy link
Contributor

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks great! so indeed the transition path looks quite sane.

as for merging, i guess as long as we don't release a version, we should be fine even if it turns out that PSR-18 still changes somehow.

please adjust the branch-alias in composer.json to 2.0-dev

CHANGELOG.md Outdated
@@ -1,5 +1,24 @@
# Change Log

## 2.0.0 - UNRELEASED

This version contains is technically a BC break because we drop PHP5 and add return
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dropping PHP5 support is no BC break. it just prevents people on an obsolete stack from updating

how do you mean "technically"? i think we should say: "This version is no BC break for consumers using HTTPlug. However, HTTP clients that implement HTTPlug need to adjust because we add return type declarations."

CHANGELOG.md Outdated

### Added

- Support for PSR-18 (Http client).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Http or HTTP? (i don't really care but we should be consistent in our doc and consistent with how fig documents write it)

CHANGELOG.md Outdated

### Changed

- [BC Break] `HttpClient::sendRequest(RequestInterface $request)` has a return type annotation. The mew
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/mew/new/ ;-)

@Nyholm
Copy link
Member Author

Nyholm commented Jul 30, 2018

Thank you for the review. I've corrected the PR accordingly.

Copy link
Contributor

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great, happy with it like this!

i'll wait a bit if @sagikazarmark has input as well

@sagikazarmark
Copy link
Member

Looks good to me. 👍

@Nyholm Nyholm changed the base branch from master to 2.x July 30, 2018 08:35
@Nyholm
Copy link
Member Author

Nyholm commented Jul 30, 2018

I've changed base to a new 2.x branch.

@Nyholm Nyholm merged commit 6885b6c into 2.x Jul 30, 2018
@Nyholm Nyholm deleted the psr-http-client branch July 30, 2018 08:36
@Nyholm
Copy link
Member Author

Nyholm commented Jul 30, 2018

Thank you for the reviews.

Nyholm pushed a commit to Nyholm/httplug that referenced this pull request Dec 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants