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.

[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/

[bwoebi]

In general, as long as we do not pay a high price for doing it [We don't.], I see no issue with supporting at least 5.6.

Especially as 5.6 support will only end simultaneously with 7.0 support in December 2018, there's no point in favoring the one over the other.

[davidwdan]

If requiring 7.0 will hold up v1 of this spec, I'm in favor of leaving it the way it is.

[bwoebi]

#2 is something where we just need a decision, I don't think it's something we can solve through discussion.

I agree with @kelunik there. Can we please just have a vote here?

If you agree to not change anything (i.e. PHP 5), please vote 👍
Otherwise, if you prefer PHP 7, please vote 👎

ping @assertchris @jsor @kelunik @trowski @WyriHaximus

[kelunik]

I guess that's a clear enough result.

[kelunik]

Do we have anything that requires PHP 5.5? callable is 5.4, but anything only available on 5.5?

[kelunik]

Currently we use finally, which requires PHP 5.5, but we could change that.

@jsor @clue @WyriHaximus Which version of PHP will react/promise and react/event-loop target with the next version? Still 5.4 like react/promise currently?

[WyriHaximus]

@kelunik Currently everything is 5.4, we have plans for PHP 7 this years starting with the loop and work outwards from there, but @jsor can tell us more what PHP 7 should come to react/promise /cc @clue

[kelunik]

If Amp requires 7.0 and React will require 7.0, then it makes sense to go to 7.0 directly and add scalar types.

[clue]

I'm not trying to cast a vote, but here's how React handles this currently:

Currently, React recommends running PHP 7+ and requires the PHP version with the features it actually requires. This tends to be PHP 5.3 or PHP 5.4, depending on the Component.

There is ongoing effort to target PHP 7+ only in future versions, but expect this to take some time, as the project cares about the existing user base 👍 Also, React will very likely keep supporting older releases for some time (possibly in some sort of maintenance mode).

[Crell]

Brief reminder: As far as the spec is concerned, only features that would be used by the interfaces are relevant. So finally isn't relevant to the spec, and thus to the version the spec targets. Scalar types in method signatures, return types, variadics, those would matter. Would those be of benefit to the spec? I don't know, that's not my call. 😄 But if they would be, go ahead and depend on PHP 7. The uptake on it has been quite good so far so I would support that if it would help the spec. (Don't do it just "on principle", but do it if it would be of use.)

[kelunik]

@Crell The Loop accessor is part of the spec and currently uses finally.

[kelunik]

Major frameworks will drop support for PHP 5: https://thephp.cc/neuigkeiten/2016/12/php-5-active-support-ends-now-what