event-loop
event-loop copied to clipboard
async-interop
Minimum PHP Version
Let's open this can of worms!
Do we (or could we) need or want any of the features in PHP 7?
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?
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.
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...
@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.
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.
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.
Sure, you can always defer to another method, but that get's ugly very quickly.
I agree, it's ugly. I was merely suggesting the limitation is not technical but preferential...
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.
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.)
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).
@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.
@bwoebi I was responding to a particular statement. I'm not honestly suggesting we build that into the implementation.
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
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?
Not much feedback on the groups thread. I like the idea of interfaces requiring ^5.6 and implementation requiring ^7.0.
Can we close this and go with PHP 5.5? Or does anyone feel scalar type declarations and return values add significant value?
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.
@coderstephen The issue aren't the developers using it but rather end users like users of https://github.com/kelunik/acme-client.
PHP 5.5 - hell callback(promise)
PHP 7 - yield from (like async/await)
Choosing obvious :)
@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.
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.
+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.
Then I'm closing it for now. If anyone has an issue with PHP 5.5, just reply / reopen.
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.
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
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/
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).
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?
