Should new PSRs support PHP5?

[Tobias Nyholm]

Hey. 

While reviewing PSR-18 I found a suggestion to make our base exception to implement \Throwable. So, should new PSRs support PHP 7 only or do we still need PHP 5 support?

Like someone said, "PHP5 is dying, just kill it already". I like to agree with that. But at the same time, I do not what the guzzle/buzz community to choose between implementing this PSR or supporting PHP5. 

I would like the core committee to give me (and other authors of new PSRs) a unified recommendation: Should new PSRs support PHP5 or not? 

// Tobias Nyholm

[Xedin Unknown]

Good question.

In our work, we always make standards compatible with PHP ^5.3. When it comes to things like exceptions, however, this is another thing, because `Throwable` doesn't exist before PHP 7. For that case, in order to formalize an interface of an exception, we have `ThrowableInterface`, which mimics the original, but can be used with PHP 5. This works for some purposes, but of course the biggest problem with it is that you can't throw it, like you can throw `Throwable` implementations. On the other hand, it's impossible to directly implement that interface either.

I work a lot with PHP 5, because many of our projects target PHP 5.4 - WordPress is quite the dinosaur. I would say this:

Support PHP 5 where it is simple to do so; for other cases, do not support PHP 5.

[Xedin Unknown]

Just in case somebody's curious about `ThrowableInterface`.

[Larry Garfield]

Naturally we shouldn't be incompatible with older PHP versions "just
because". However, at this point in time if a spec would benefit from a
PHP 7.0 feature I fully support using it. (7.1 is too aggressive, I
think, but 7.0 shouldn't be.)

Scalar and return types are the most likely feature to trigger a PHP 7
dependency since those are the ones that matter most to interfaces, but
in general, yes, if a spec would be better with PHP 7.0 features, use
PHP 7.0 features. It's 2017, PHP 7 uptake is very good compared to the
PHP 5 transition, and many many major projects either already require
PHP 7 or will within the next year.

--Larry Garfield

[Chris]

On Sun, 2017-10-22 at 05:34 -0500, Larry Garfield wrote:
> On Sat, Oct 21, 2017, at 03:19 PM, Tobias Nyholm wrote:
> > Hey. 
> >
> > While reviewing PSR-18 I found a suggestion to make our base
> > exception to 
> > implement \Throwable. So, should new PSRs support PHP 7 only or do
> > we
> > still 
> > need PHP 5 support?
> >
> > Like someone said, "PHP5 is dying, just kill it already". I like to
> > agree 
> > with that. But at the same time, I do not what the guzzle/buzz
> > community
> > to 
> > choose between implementing this PSR or supporting PHP5. 

I think there is a chicken and an egg problem here. If we as the FIG
continue to outwardly support PHP 5 backward compatibility, we are
potentially hamstringing ourselves for the sake of libraries instead of
creating standards on modern code. And if our PSRs are specifically
targeted at PHP 5.x, then that allows libraries to stay there longer.

Personally, I'd rather see a greater adoption of PSRs that are geared
toward making lives easier and making sane standards, but not at the
sacrifice of compatibility on non-supported versions of the language.

If a library wants to continue to support a non-supported version of
PHP... well, then that's on them, whatever their reasoning may be.

> >
> > I would like the core committee to give me (and other authors of
> > new
> > PSRs) 
> > a unified recommendation: Should new PSRs support PHP5 or not? 
> >
> > // Tobias Nyholm
>
> Naturally we shouldn't be incompatible with older PHP versions "just
> because".  However, at this point in time if a spec would benefit
> from a
> PHP 7.0 feature I fully support using it.  (7.1 is too aggressive, I
> think, but 7.0 shouldn't be.)   

I'm in agreement with Larry. It's 2017, PHP 7.0 has been out for a good
while now, and, honestly, it's well past the time that PHP 5.x was
supported.

>
> Scalar and return types are the most likely feature to trigger a PHP
> 7
> dependency since those are the ones that matter most to interfaces,
> but
> in general, yes, if a spec would be better with PHP 7.0 features, use
> PHP 7.0 features.  It's 2017, PHP 7 uptake is very good compared to
> the
> PHP 5 transition, and many many major projects either already require
> PHP 7 or will within the next year.

And I agree with this as well. Just because PHP7 has static type
hinting or other features doesn't mean a spec _must_ use it. I rarely
use a bunch of PHP 7 features, but target PHP 7 for new code just in
case.

>
> --Larry Garfield
>

-Chris Tankersley

[Sara Golemon]

Given that PSRs packages are just interfaces, the problem space comes down to type hinting and that’s basically it. There’s no need for an interface only file to have a declare(strict_types); declaration since it has no effect on a file with no real code. The nature of exceptions (implements \Throwable versus extends \Exception) falls on the edge of the type hinting issue.

So the question is: How much do we want scalar type hinting (and return type hinting, throwable, iterable) in PSRs?  Do we want these things enough to exclude PHP 5 consumers? More to the point, who is our real audience? I don’t think our audience is WordPress (still defining their minimum version as 5.2.5). Is our audience a bunch of green fielders who are pulling in Symfony 4 (which requires 7.1+) ?

My hot take is to generally agree with Larry (7.0+ is reasonable where there's a demonstrable benefit, but 7.1 borders on aggressive).  I don't quite agree that it's /too/ aggressive, but it should be tempered by some degree of conservatism.

Personally, I'd like to hear from project reps.  What are your various positions on minimum versions?

-Sara

[Alexander Makarov]

7.1 should be fine. 7.0 has a limitation for not allowing nulls while type-hinted and that's a deal breaker.

[Oscar Otero]

I’d like to have a more progressive approach. Something like this:

v1.0 => PHP 5.6

v2.0 => PHP 7.0

v3.0 => PHP 8.0

etc...

Defining a way to upgrade packages with no API modifications, but just requiring newer php version makes the psr more version agnostic. The most important thing is the api spec, not the features of any php version. Older php versions makes more use of docblock and newer php versions use the new syntax features. It’s like progressive enharcement strategy applied to php.

--
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/e4b31600-770b-4d26-a9b6-5e0114dd04ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Cullum]

Oscar,

This was discussed on Slack however those there agreed it didn't make sense to do releasing new version of the interface for each PHP version.

The reason being as then you have a client application that has one library requiring one version, and another library requiring another version which would be incompatible with each other.

Implementing libs also couldn't support both 1.x and 2.x if they support PHP 7 as you can't leave out the type declaration of extending an interface, and having it in PHP 5 will throw an error. So implementing libs would require 1.x or 2.x but never both causing the above issue in client applications.

Michael

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@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/e4b31600-770b-4d26-a9b6-5e0114dd04ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@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/58C2F471-8E84-4DA7-AEB6-F2E78F3393CC%40gmail.com.

[Oscar Otero]

Ok, I see.

Could this be solved with php 7.2, that implements parameter type widening? (https://wiki.php.net/rfc/parameter-no-type-variance)

So we can keep releasing interfaces compatible with php5 and in a short future release the v2.0 compatible with php ^7.2.

I think that this feature was added specially for things like this.

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/CAAqcDMj7nuahPK86RVPT%3DQ%2B0fFAqBu0LzZ3tZKuu%2Bi4Q8EEtJA%40mail.gmail.com.

[Xedin Unknown]

That's, actually, my point. Because in coding terms standards are just interfaces, it takes a very small amount of effort to make them compatible. If, instead of type-hinting scalars, you just specify the right types in the docs, that is enough to make a standard. PHP 7 implementations are free to type-hint in the code, if they need, but this doesn't make the standards themselves worse by any means.

Also, I agree with you that the majority of WordPress developers are not using PSR, but I am, and I would argue that a lot of devs are moving to PHP 5.6. In fact, Joost de Valk has created a whole movement, pushing other devs to switch. I try to do my best to make platform-agnostic packages, and therefore it's kind of important that WP devs have the possibility of writing PSR-compatible code.

[Lukas Kahwe Smith]

On 28 Oct 2017, at 20:23, Oscar Otero <oscar...@gmail.com> wrote:

Ok, I see.

Could this be solved with php 7.2, that implements parameter type widening? (https://wiki.php.net/rfc/parameter-no-type-variance)

So we can keep releasing interfaces compatible with php5 and in a short future release the v2.0 compatible with php ^7.2.

I think that this feature was added specially for things like this.

El 28 oct 2017, a las 19:54, Michael Cullum <m...@michaelcullum.com> escribió:

Oscar,

This was discussed on Slack however those there agreed it didn't make sense to do releasing new version of the interface for each PHP version.

The reason being as then you have a client application that has one library requiring one version, and another library requiring another version which would be incompatible with each other.

Implementing libs also couldn't support both 1.x and 2.x if they support PHP 7 as you can't leave out the type declaration of extending an interface, and having it in PHP 5 will throw an error. So implementing libs would require 1.x or 2.x but never both causing the above issue in client applications.

I also brought this up, not because I am not aware that this can lead to messy situations but in order to give one less reason not to support return type hinting in new specs.

Finishing a PSR and getting it into libs and then integrated into frameworks in a stable release takes long enough. Lets not end up in a situation where PSR compliance means being 1-2 PHP versions behind in terms of features.

In this spirit I propose to always allow (maybe even mandate) using the latest PHP versions in PSRs. As well as encouraging updating existing PSRs (though maybe not necessarily for every PHP release with relevant new features ..). For the most part we are only affected by things that impact interfaces (ie. new type hinting, new classes etc), 

regards,

Lukas

[Larry Garfield]

"Just put the types in docblocks" is unfortunately insufficient.  Exhibit A: PSR-6 specified a method that needed a date time, and would accept either DateTime or DateTimeImmutable, aka would take DateTimeInterface from PHP 5.5.  At the time we decided to make it a docblock-only type to allow PHP 5.4 and 5.3 compatibility, which unfortunately means there are now PSR-6 implementations that handle the error case (someone passing an int timestamp, for instance) in different ways.

It's not the happy-path, but handling of error conditions is absolutely an important and relevant part of a specification.  See also: the HTML5 spec is 80% documenting error handling conditions for the first time by retconning all the different things browsers ended up doing. :-)

My proposal:

"A spec SHOULD target a minimum version of the oldest supported PHP version at time of release. It MAY target an earlier or later version if functionality in those later versions would offer substantial benefit.  It MUST NOT target a PHP version that no longer receives security support."

That implies:

1) We still have wiggle-room for individual specs as appropriate that can be sorted out by each WG and the CC.

2) It makes it clear that by default we support what PHP-Internals support, so we have a "default position" to fall back on in case of irreconcilable disagreement.

3) Would currently imply "target 7.0 unless there's a very good reason otherwise."

4) A year from now would imply "target 7.1 unless there's a very good reason otherwise."

5) Gives us one more year of "you can target 5.6 if you really really need to", but:

6) Gives a very clear EOL for PHP versions that a spec will target.

7) Since as noted most languages features don't actually matter to interfaces, it's entirely possible that a 7.2-targeting spec will still be compatible with 7.0.  That's totally fine if it happens; there's no reason to actively break support without cause.  But "don't use iterable, that would break 7.0 compatibility" would not be a valid argument.  (It *is* a valid argument today, but it wouldn't be in 2 years, and we know that ~2 years in advance.)

*dons flame retardant suit*

--Larry Garfield

--

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/a67e9ae8-506c-49ce-842e-45f5e3617d40%40googlegroups.com.