On Mon, Jun 25, 2018 at 7:30 AM, Zeev Suraski <z...@zend.com> wrote: > As I mentioned a few days ago I intended to send it slightly later - but as > Nikita brought up the topic of PHP 8, this is probably as good a time as any > to start the discussion. > > Please note: The goal of this email isn't to discuss in detail each and > every topic that's mentioned, but rather to establish whether we want to move > to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research > projects and PoCs we've been working on. > With the above paragraph in mind, I would say yes; This laundry list sounds like major bump worthy items. However I'm going to throw some negatives in here and probably start longer threads separately on my concerns with specific items.
1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into 7.3 which is already in fire-hose mode of last-minute, under-planned "hey I want this toy" requests. Yes, deprecations are a little bit more sweaty ice cube in terms of late deprecations being lower risk that late additions, but it's still turning into a rushed thing during a season when some folks are off on holiday break. The FF is in Summer in part *because* this is a bad time to introduce RFCs. 2/ In several of theses cases we're talking about something that's not even fully scoped out yet. Async, for example, "requires a lot more research". Yes, that research can probably be completed and turned into an implementation in the 1.5 years we have till the Nov 2019 GA (whatever version that ends up being), but there are multiple items on this list which are not (seemingly) fully fleshed out. 3/ When I read phrases like "open the door for new types of workloads for PHP (non Web)", and "one of the key reasons Node is gaining popularity", and " 'bleeding edge' technologies, such as AI and Machine Learning" I smell a trend of chasing the new hotness and worrying about factors other than making PHP the best language for the Web. Growing PHP is great, and evolving it into new areas is also potentially quite good, but we *have* history showing what happens when we come up with something new to chase after that then turns out to be underwhelming, undermaintained, and underutilized. I've also seen what a JIT does in terms of additional complexity, it's not pretty. 4/ When the $(%* did we body swap, because it's not quite full turnabout, but I'm suddenly having flashbacks of "give the language a rest". :) Please don't construe this response as entirely negative. As I said in other replies, I'm actually quite excited about these new things and the directions they open up, and it may be that you and Dimitri have been spending quite a lot of time thinking about them and their implications to the language going forward. However, like the NG branch prior to 7.0, most of this appears to lack any sort of plan for those of us not in your private email threads. Yes, we've discussed all of them at one point or another, but apart from the JIT, there's been no obvious signs of work on any of them, which brings me back to being concerned about 7.3 suddenly being flagged as the last 7.x release within mere DAYS of its planned feature freeze branch date without warning. Possible alternative. Still aim for Nov 2019 GA of 8.0, but have a 7.4 in parallel with it. This (sort of) happened with 4.4 being released between 5.0 and 5.1 (I know, not quite the same). This would give us a couple advantages: 1/ Take our time with these last-minute "deprecate all the things" RFCs that have suddenly popped up. 2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations for the big stuff aren't quite ready for whatever reason rather than being forced to push them to 9.0 Downsides, obvious: More merges for bugfixes and RM overhead, plus Remi and Stephen's time with Fedora/Win32 builds. We did this for the 5.x-7.x jump, I say we can do it here. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
