Update to PHP7

[oanhnn]

I think we should update to PHP 7 (like psr/http-factory package):

• PHP 5 is deprecated (PHP 5.6 Security Support Until 31 Dec 2018)
• Using typed parameters and return value of PHP 7, interfaces is clearly visible.

[GrahamCampbell]

This is a major breaking change. I think this would require a new PSR?

[webignition]

I'd say that a new PSR is not needed.

This is a breaking change for a minor release. If this was merged and then released as 1.0.2 or 1.1 (the current next logical release numbers), current PHP 5.6 users would have a very bad time. To merge and release as a minor version is quite clearly a bad choice.

This is not necessarily a breaking change for a major release.

We could merge and release as 2.0. The 1.x releases would exist for legacy (PHP < 7) users. The 2.x and onwards releases would exist for PHP >= 7 users.

Future changes would need to be applied to both the 1.x and 2.x releases. That's a little more work but given the relatively small size of this package I'd not consider the additional work to be overly burdensome.

Is there any release policy that prevents this approach?

[codemasher]

...which reminds me that i already did this https://github.com/php-fig/http-message/compare/master...codemasher:type-hints-php7.1 ~~Might aswell submit a PR?~~ v2.0 => PHP 7.0, v2.1 => PHP 7.1 (void & iterable)

[EvilFreelancer]

@codemasher hello, by psr-12 reasons can you please add one space after the colon followed by the type declaration? Thanks.

[codemasher]

There you go: https://github.com/php-fig/http-message/compare/master...codemasher:type-hints-php7.1

I've also changed the array type parameters of ServerRequestInterface::withCookieParams() and ServerRequestInterface::withUploadedFiles() to iterable to allow more flexibility.

[McLotos]

This is a major breaking change. I think this would require a new PSR?

Not needed. The whole serious developers use composer. Others may don't know about PSR. PSR7 Must have a new branch (new tag for composer) for PHP7+ and save compatible with old PHP version in old branch. At 2k19 not using a type hinting for arguments is bad practice.

[ghost]

Have you considered files above ~2gb and integer overflow?

Methods like StreamInterface::tell() : int; and StreamInterface::seek(int $offset, int $whence = SEEK_SET); shouldn't be restricted to integer only.

[andig]

This would only be a problem on 32bit flatforms. Its int in php, too: https://www.php.net/manual/en/streamwrapper.stream-seek.php

[codemasher]

In addition to a PHP 7 upgrade, i'd like to propose to allow chaining of StreamInterface::seek() and StreamInterface::rewind() (https://github.com/codemasher/http-message/commit/05c9c0bd399029a4ab8f81c35dbc49b70938ca0f)

$message->getBody()->rewind()->getContents();

[jasny]

@McLotos What's holding the merge of this PR / releasing it back?

[GrahamCampbell]

@jasny Because this PR could be considered a change to the spec, and is certainly a major breaking change to the interface. There was discussion over if a new PSR is needed, or just a major version bump on the package. There are also implications for the virtual http-message package on packagist, which lots of people have dependence on * rather than ^1.0.

[jasny]

@GrahamCampbell If the outcome of the discussion was that a new major version isn't an option, maybe close this (and other) PRs. At least, then it's clear they won't be merged.

[MarkusRodler]

If other people uses wrong dependency version strings (e.g. *), then that is their fault. SemanticVersioning FTW. At least I am sure that they can fix their dependencies within seconds and I am sure that I will not stick to pre-7.0 standards that are outdated / state of the art. No interchangeability for me but I have type-safety.

This is only my opinion on this topic.

[GrahamCampbell]

If other people uses wrong dependency version strings (e.g. *), then that is their fault. SemanticVersioning FTW.

Well, this was on a virtual package, which has no versions.

[McLotos]

I think, our discussion go to wrong way. What about this merge request and next public release?

[GrahamCampbell]

I think, our discussion go to wrong way.

I don't agree. The PSR Amendments Bylaw doesn't allow changing the signature of interfaces, which blocks this PR: https://www.php-fig.org/bylaws/psr-amendments/.

[MarkusRodler]

Well then I see 3 possible ways out of this dilemma:

1. Add a chapter in the PSR Amendments to allow versioning if newer PHP techniques are available
2. Alternatively create additional PSRs for every "standard" that is out-of-date
3. Or close all pull requests and stay with the non-strict-way

I don't know if it is possible to do the first one. The second one causes a huge process I think and the last one is no option in my opinion.

[Jean85]

We've been discussing this kind of issues a lot lately, and we've condensed our proposed solution to updating PSR interfaces in a blog post. Please read it and provide your feedback!

https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/

[McLotos]

Hi @GrahamCampbell ! 2 years yet have passed, so when we can get a typed version? =)

[codemasher]

Hi @GrahamCampbell ! 2 years yet have passed, so when we can get a typed version? =)

An entire majpr PHP version has passed! Sorry, but at this point it seems more feasible to issue an RFC for PHP to allow adding method parameter type hints for poorly typed interface methods.

[McLotos]

Hi @GrahamCampbell ! 2 years yet have passed, so when we can get a typed version? =)

An entire majpr PHP version has passed! Sorry, but at this point it seems more feasible to issue an RFC for PHP to allow adding method parameter type hints for poorly typed interface methods.

But in other packages it already done

[oanhnn]

V2.0 support >= 7.0 V3.0 support >= 8.1 (Add Enums, readonly, ...)

https://w3techs.com/technologies/details/pl-php

[weierophinney]

#94 and #95 do the appropriate steps that follow the PSR Evolution bylaw. As such, those will be what I use for the evolution vote, and I am closing this one.

BTW, @oanhnn : please read the bylaw. Adding enums, readonly support, etc. is out of scope as that would be substantive changes to the spec, and would require a replacement PSR.

[McLotos]

#94 and #95 do the appropriate steps that follow the PSR Evolution bylaw. As such, those will be what I use for the evolution vote, and I am closing this one.

BTW, @oanhnn : please read the bylaw. Adding enums, readonly support, etc. is out of scope as that would be substantive changes to the spec, and would require a replacement PSR.

current PSRs so outdated that it lost all reasons