Minimum PHP Version

[AndrewCarterUK]

Let's open this can of worms!

Do we (or could we) need or want any of the features in PHP 7?

[WyriHaximus]

Right, I have mixed thoughts on this.

• What do we really NEED for the interface and what is the minimum version needed for that?
• What is the current lowest support version of PHP? (At the time of writing that is 5.5 but with security fixes only: http://php.net/supported-versions.php)
• Async is still new a very shiny for PHP, can we be progressive enough to jump to PHP7?

[trowski]

I'm struggling a bit with this same question with Icicle. I'm currently supporting PHP 5.5+ and 7, but with different, incompatible branches because PHP 7 brings so many shiny features for async. As far as I'm aware, most people using Icicle are using the PHP 7 only branch.

My gut feeling is to support PHP 7 only, since async is such a shiny new feature that 7 will be old before we see wide adoption of it. Why hinder ourselves by supporting a version it is unlikely anyone will use? The interface can be much more explicit with PHP 7 since we can specify scalar parameter types and return types.

[assertchris]

My feeling on this is that the interface(s) should be compatible with ^5.6 and ^7.0, but the implementation could be compatible only with ^7.0. Let's make it someone else's problem to implement a ^5 version...

[kelunik]

@assertchris You can't make the interfaces ^5.6 and ^7.0 compatible, but the implementation only compatible with ^7.0. Well, you can use 7.0 features of course, but you can't use scalar type declarations and return type declarations, because the interfaces must be compatible.

Only reason to use 7.0 would be return type declarations and scalar type declarations.

[kelunik]

The issue is not developers not using a up-to-date version of PHP, it's actual software that may have to support PHP 5.5, because many users can't upgrade yet, e.g. https://github.com/kelunik/acme-client which should be able to run on many hosts.

[assertchris]

You can't make the interfaces ^5.6 and ^7.0 compatible, but the implementation only compatible with ^7.0. Well, you can use 7.0 features of course, but you can't use scalar type declarations and return type declarations, because the interfaces must be compatible.

Unless I'm mistaken...

[kelunik]

Sure, you can always defer to another method, but that get's ugly very quickly.

[assertchris]

I agree, it's ugly. I was merely suggesting the limitation is not technical but preferential...

[bwoebi]

I think it's valid to require minimum PHP 5.6, but the differences in regard to what we need for a reactor are minimal between 5.5 and 5.6 … So, as long as there is no particular benefit for 5.6, we should just require 5.5.

Sure, we could want PHP 7, makes some things easier (hello ?? :-)), but due to PHP 5.6's long support (31.12.2017 - phew!) we should be PHP 5 compatible.

[WyriHaximus]

Rather keep it clean and refrain for ugly hacks. Yet I might propose one:

The problem, as @kelunik describes, is supporting actual systems. Many should be 5.5+ by now but the vast majority isn't on 7 yet. Some are even on as low as 5.3, a lot of embedded system barely to never update their PHP version. Looking at wordpress they just recently removed support PHP4 style constructors. Now that isn't our target audience, but it sets a precedent for shared hosting not to update to the latest version very fast. Or even managed hosting where the current version is 5.5 or even 5.4 because of OS of choice or what ever reason they have. Depending on the company could be locked to those versions. (I've seen servers running 5.2 barely a couple of years ago.) Doesn't make it how we would like to see it, or how many community members like to see it but it is the reality.

I'm really torn between PHP 7.0+ and lots of shiny features and supporting 5.5/5.6 for those stuck on 5.

One thing that comes to mind is have a 1.0 version of the interface only targeting ^5.5 and 2.0 targeting ^7.0. (Really just tossing a wild idea out here not sure if it should or would work.)

[bwoebi]

No, please don't go that eighth circle of hell with maintaining two different versions for PHP 5 and PHP 7.

We can do that once 5.6 is EOL, but have both simultaneously, please.

That's btw. also going to cause conflicts if you want to use a library using ^1 and one using ^2 (because PHP 7 only).

[bwoebi]

@assertchris tiny note: this will btw. break the premise of declare(strict_types=0/1) as you take the strict/weak decision outside of callers control.

[assertchris]

@bwoebi I was responding to a particular statement. I'm not honestly suggesting we build that into the implementation.

[bwoebi]

Sure, I assumed that, just saying ;-)

[AndrewCarterUK]

I've posted a thread about this in the FIG group to see if we can get any more opinions on the topic: https://groups.google.com/forum/#!topic/php-fig/-sgoBVwclD4

[Crell]

PHP 7 has a lot of nifty new features that help async; I believe @trowski was partially responsible for yield from, for exactly that reason. However, the only features relevant to the interfaces would be scalar typing and return types.

So the question is, how valuable are scalar types and return types to the async interfaces?

[assertchris]

Not much feedback on the groups thread. I like the idea of interfaces requiring ^5.6 and implementation requiring ^7.0.

[kelunik]

Can we close this and go with PHP 5.5? Or does anyone feel scalar type declarations and return values add significant value?

[sagebind]

While I can't personally picture a large crowd of people seeking to use this who aren't able to use PHP 7+, I think it is reasonable to require PHP 5.5+. I don't have a strong opinion either way.

[kelunik]

@coderstephen The issue aren't the developers using it but rather end users like users of https://github.com/kelunik/acme-client.

[ParkFramework]

PHP 5.5 - hell callback(promise) PHP 7 - yield from (like async/await)

Choosing obvious :)

[kelunik]

@ParkFramework PHP 5.5+ has support for yield and with Amp\resolve() you don't need yield from. Furthermore, the event loop itself isn't currently bound to any promise API.

[WyriHaximus]

My preference goes to 5.5 as well. Like @kelunik mentions it's not the developers it's the users. I'm personally porting all my projects to 7, and only my brand new OSS projects are 7+. But this is a project with a greater impact then my personal things, and as such it should be accessible to a wider audience. @kelunik's LE client is the perfect example.

[trowski]

+1 for 5.5. While I think most would use 7 for new async projects, after further consideration I'd hate to so quickly exclude those who can't upgrade for reasons beyond their control. 5.5 has yield which is sufficient to write async code that isn't awful.

[kelunik]

Then I'm closing it for now. If anyone has an issue with PHP 5.5, just reply / reopen.

[kelunik]

Given #79, it might be worth pushing the minimum version to 5.6. Unfortunately, people decided to support 5.6 until the end of 2019, so I think there will be a lot of people not upgrading that fast.

On the other hand, it's great that Debian (in testing, release probably Q1 or Q2 2017) and Ubuntu (in 16.04) have 7.0 and that will definitely help upgrading.

[WyriHaximus]

Even on older Ubuntu (LTS) versions getting both 5 and 7 on the same box is easy with Ondřej Surý's PPA.

I'm supporting the move to 5.6 now that 5.5 is almost EOL

[kelunik]

Kicks default Ubuntu 14.04, but for Ubuntu there's the PPA, so I think that's fine. See also http://phpversions.info/operating-systems/

[assertchris]

Jordie's stats show 5.6 is still the most widely used version (with 7.0 usage up from November): https://seld.be/notes/php-versions-stats-2016-1-edition

Edit: I started that comment saying down (but I meant up).

[joshdifabio]

Jordie's stats show 5.6 is still the most widely used version (with 7.0 usage down from November): https://seld.be/notes/php-versions-stats-2016-1-edition

I think one of us has misread the figures, because the linked page seems to suggest that 7.0 usage increased from 1% in November to 20% in May?

[bwoebi]

When we anyway don't support 5.5; why not just immediately go with 7.0 (which is already quite widespread)… I don't really see a point resting stuck with PHP 5 when the small jump to 7.0 gives us types, a few less version checks and (where used, clean coroutines without weird "last yield" or CouroutineResult insteance yields …)

Also, I suspect 7.0 usage to go up a lot in August/September after 16.04.1 (i.e. after do-release-upgrade is available by default on 14.04)...

[joelwurtz]

IMO There is a strong adoption of PHP 7 (at least for people already on PHP 5.6) due to the performance boost on production server and a very slow cost for upgrading (no big BC at the exepection of some exotic extension)

So by the time this spec would be ready and some implementations available, PHP7 will certainly be the leading version.

[geggleto]

As an outsider, I think it makes most sense to write for 7.x only. I would spin up 7.x servers if I were going to deploy an async app, not use my current 5.6 ones.

[trowski]

I'd rather stick with 5.5 as a min requirement as I think support from ReactPHP will be a big influence on pushing this standard to be mainstream, and I doubt ReactPHP will want to move to requiring 7.0 so quickly. @WyriHaximus maybe you have a comment on this?

[geggleto]

@trowski I humbly remind you that 5.5 is EOL in less than a month :) 10 July 2016.

[WyriHaximus]

Tbh I think @cboden can better answer that then me, but I don't see it happy anytime very soon

[bwoebi]

As we seem to have decided to not need 5.6, there's no reason why not to support 5.5. Implementations may base their code on a higher minimum version if they need to.

Closing now… if there's anything left to discuss, it may be reopened.

[kelunik]

I want to rediscuss this. RxPHP will require PHP 7. Amp will require PHP 7. PHP 5.6 is in security-only support now. PHP 7 has been bundled in Ubuntu 16.04 and other distributions.

[kelunik]

This relates to #117 as well. Using strict types is only possible without warnings if we require PHP 7 as a minimum.

[assertchris]

Agree, ^7.0 makes more sense, especially given the recent announcements of Laravel, Symfony, PHPUnit etc. to require it.

[kelunik]

If we go with ^7, should we do the same for async-interop/promise? I think we don't really gain something there.

[davidwdan]

The only benefit I see with async-interop/promise requiring ^7 is that the when callable can require a Throwable

[kelunik]

@davidwdan I thought that, too, but it's not even true, as that interface just declares callable. I'd be the callback that can declare Throwable, but it can do so independently.

[trowski]

@jsor What version of PHP will the next version of react/event-loop and react/promise target?

[davidwdan]

You're right it's not part of the interface, but it is part of the README:

$callback – A callable conforming to the following signature:

PHPfunction($error, $value) { /* ... */ }

[joelwurtz]

Also having PHP 7 grants the possibility to use anonymous class, then there is the possiblity to have a better type hint for the promise interface (having an interface instead of a callable, and type hinting the __invoke method of the interface), like the following

interface PromiseResolver {
    public function __invoke(\Throwable $error, $value);
}

interface Promise {
    public function when(PromiseResolver $resolver);
}

Then you can detect error when writing error at the compile time of php and not on the runtime (which can become very hard to debug in async context).

[kelunik]

@joelwurtz I think that's not going to happen. We want a lightweight interface. Application code should primarily use coroutines anyway, so doesn't have to care about when.

[jsor]

@jsor What version of PHP will the next version of react/event-loop and react/promise target?

@trowski No plans to change this, so still 5.4.

[WyriHaximus]

@jsor What version of PHP will the next version of react/event-loop and react/promise target?

@trowski No plans to change this, so still 5.4.

@jsor maybe we should discuss our PHP version targeting internally since 5.6 is about to become EOL

[bwoebi]

@WyriHaximus s/EOL/sec-only for another 2 years/