> -----Original Message----- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Monday, June 25, 2018 11:43 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 2^3 > > That's certainly a good argument for the people doing deep engine work to > focus on that, but there's ample non-core-team people who would be totally > useless in stabilizing a JIT that could have other things to add. I'm thinking of if, > say, SammyK comes back with another trailing comma RFC again, or someone > not already busy with async details manages to figure out a performant way to > do property accessors, etc. Would those be actively blocked from 7.4? Or > would those be fine as long as it doesn't distract you and Dimitry from figuring > out async?
The reality of things is that very few patches make it into the engine without the (very few) core engine developers closely reviewing them, and sometimes greatly refactoring them. It might feel like it's happening automatically, but it doesn't - it's a lot of effort. Separately, it wouldn't or at least shouldn't be "Dmitry figuring out async". It needs to be a group effort, which I'm sure Dmitry would greatly contribute to - especially around the infrastructure - but then there'll likely be the group effort of async-enabling our various extensions. Letting the core devs do the heavy lifting while the rest are playing with other things isn't a very nice or sustainable strategy. And as unpopular as this may be, this should (IMHO) be primarily up to the core devs who are in fact doing the heavy lifting - we need to design the development schedule to make their job the easiest, as it's already remarkably tough. > If they're OK, then yay, we're on the same page. If not, then we're basically > guaranteeing that no one is going to bother using 7.4 (thus rendering the whole > "deprecation release" useless) and losing a lot of momentum from people > interested in improving the language in ways other than the core runtime/ > compiler logic. As I mentioned elsewhere I do see value in it even if it's a deprecation-only version, effectively a 7.3.(n+1) with deprecations, where migration costs are no different than to any other 7.3.x (i.e. very low, guaranteed), and you get a version that can ease you into PHP 8 around a year ahead of time. We could even just introduce a certain switch allowing you to enable these deprecations in a real 7.3.x release, without calling it 7.4 now that I think of it. Note that it's not just about the raw amount of coding or discussion hours - it's also about the state of mind. If our top goal after 7.3 is to release 8.0 - I'm sure people can figure out ways to help this cause. If we have two concurrent projects, people would go for their comfort zones. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
