On Mon, Jun 25, 2018 at 9:58 AM, Zeev Suraski <vsura...@gmail.com> wrote: > Note that I did propose that we actually have a thin depredations-only PHP > 7.4 (to give credit where credit's due, that's Dmitry's idea). This gives > us ample time without having to rush deprecations into 7.3 > I apologize. I had missed that in my initial reading, but you certainly did propose that (or rather, Dimitry did, I suppose). I agree with this tack.
> I think it's entirely unreaslitic (or remarkably optimistic if you prefer) > to think we'd have this done in under 18 months. There's still tons of work > we'd want to do in the JIT front, the work is entirely ahead of us as far as > async and preloading are concerned - and that's without even factoring in > the amount of time that discussions would take nor the fact we're likely to > still be busy with 7.3 for quite some time. Releasing it at the end of 2019 > effectively means we can squeeze such a huge version in the same timeline we > took for incredibly smaller versions like 7.1, 7.2 or 7.3. I think we're > good, but we're not THAT good :) I also don't think there's anything > 'sacred' about releasing at the end of a particular year. > Yeah, like I said, I must have completely missed that entire paragraph. Mid-2020, following a late-2019 release of a "light" 7.4 with deprecations is reasonable, though I don't think it'd be such a bad idea if we kept it on schedule to GA 8.0 with all the goodies in Nov 2020. As alluded, I kind of like that FF happens in the summer when things *should* be relatively slow otherwise. > First, I'll admit that there's definitely some of that happening. But to > paraphrase my daughters - "I didn't start it!". In other words - people are > very actively looking for ways to run PHP in a Node-like manner, and with > the shift towards micro-services - I don't think it's a fad. I think we > need to go there if we are to stay relevant. > Fair point. I've certainly had discussions with Liz Smith and even been on Zend sponsored podcasts discussing ways we might "appify" PHP. But, and perhaps I'm just a bit more skeptical of the microservices train, I think we should be judicious in our pursuit of the new hotness. That's all. Most of my response was centered on what felt like a rush. Factoring in that entire paragraph about having a thin 7.4 release with a subsequent 8.0 GA alleviates my concerns a great deal. > With JIT - it's bit of a mixed bag. After so many efforts went into it and > we managed to get something pretty nice going - it was also a bit of a > solution looking for a problem. That's where the idea of expanding PHP to > other areas came from. And to be perfectly honest - it's not that I > invented this approach either - people have been using PHP for non-Web > workloads since forever. Plus, we're still hopeful that it would show > benefits for the Web world, especially in conjunction with preloading and > the fact it'll enable PHP-based built-in functions (which is another thing > we've wanted for a long time). > Right. And I'll add that although this same thing is true of HHVM's JIT (that it's actually kind of naff on common web workloads), it's also true that taking the wider view which includes things like whole program analysis (a factor of which is the pre-loading you mentioned) does make the usability of the JIT more impactful. I would also be the last to argue against the ability to deliver some of PHP's standard library in script form. There are even places where this can provide a marginal, but non-zero gain over C implementations since marshaling between internals and user-space code can be avoided, or branches within the implementation can be elided by the optimizer. Ya can't optimize what you can't see, and the optimizer can't see AoT compiled C code. Again, not arguing against any of these things in their own right. I certainly appreciate the work that Dimitry and you and putting into making this happen. My only concern (and I'll admit it's slightly spurred by Niki's last minute proposal for typed properties) is timing and our proximity to PHP-7.3's branch point. > Again, the main goal here is to > gauge the level of willingness of people to say that PHP 8 is going to be > the next feature release of PHP after 7.3, and to allocate a longer timeline > for us to successfully deliver it than the standard yearly cadence (as was > pretty much always the case with major versions). > And based on the timetable that I realize I should have seen but missed, you've got my vote. > I still think that Dmitry's idea that we have a deprecation-only 7.4 > sometime in 2019 makes sense. If we really wanted to we could make it a > deprecation+some extras version, but I'm concerned about fragmenting our > scarce resources. I don't think the sky will fall in case we take 18-24 > months between our last 7.x feature release and 8.0. We've had that between > 5.6 and 7.0 and I think it worked pretty well. > I'm not against some features for 7.4. I'd even say Niki's typed properties (which isn't a minor change) can slot in there happily enough. But we can dig in deeper over time on that. Maybe he gets it into 7.3? ¯\_(ツ)_/¯ -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
