On Thu, Feb 14, 2019 at 12:17 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On Thu, 14 Feb 2019 at 09:43, Zeev Suraski <z...@php.net> wrote: > >> Does it mean that when PHP 8.0 comes out (in roughly two years' time most >> probably), we'd be saying this is experimental? Or that only in the >> meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before >> it's released, we'd say it's experimental but will remove that tag by the >> time 8.0 is released? >> > > > The latter. Every new feature is experimental until it's released; scalar > type hints were experimental in master until 7.0 was released; typed > properties are experimental until 7.4 is released; I don't see why this > should be any different. > I'm pretty sure we've had experimental features in released versions. To me tagging something as experimental in master while it's in early development stages is somewhat superfluous - the whole of master should be considered pre-alpha / alpha until it goes to beta. That's why I was asking. > Offering it as >> something experimental (i.e. not for production) in 7.4 can help us with >> that goal, as it will make it easier for a wider range of people to >> experiment with it and provide feedback. >> > > > As I mentioned in a previous e-mail, I'm not clear who these extra users > are, or what value their feedback will be. > I'm not sure who they are either, but much like we've had several folks here on internals report back their experimentation with JIT, I think casting a wider net will likely result in more feedback. On one hand, if someone tests their application on a stale version of the > JIT engine released with 7.4.0, and says "it segfaults when I foo" or "I'm > surprised it doesn't optimise bar", the answer is likely to be "we fixed > that 6 months ago in master". > And that could be a very reasonable answer; Given that it's an experimental feature that someone purposely decided to build and enable, telling them that they can get a more recent version of JIT by using master is not an unreasonable response. > On the other hand, if someone is confident enough to enable an > experimental JIT feature on a server, they're probably fine with running a > pre-alpha snapshot, or building it from source (e.g. by downloading > Rasmus's vagrant box). > We seem to agree, but there's no doubt in my mind that 7.4 will reach a much wider audience than folks who are here on internals. In a nutshell, the fact that they can get a pre-alpha PHP 8 that has JIT, doesn't mean they know it even exists. Including it in 7.4 can help advertise that - of course, other than the fact that I'm sure in many cases it will actually work, enabling them to provide us with real world feedback without having to upgrade to master/8. If we thought that all of them would be bumping into trouble, we wouldn't be proposing it as an option. > If the feature was "mostly finalised but needs more testing", then an > experimental release might make sense; but that's not the impression I get > here, as it's been said over and over that deeper changes are needed to get > the full advantage, and that's why we need PHP 8 in the first place. > Actually, I think it's closer to being "mostly finalized' than it is to requiring a major overhaul. It's our 3rd attempt at it after spending the better part of a decade working on it, and while there's always room for improvement - and there are some specific areas that aren't yet done (platform support, ZTS, etc.) - I don't think we're likely to see fundamental ground-breaking changes. The most common PHP use case - Linux x86/x86_64 single threaded - is probably fairly close to what it will be. Again, like I told Nikita I think that whether or not we include it in 7.4 is a tactical decision (and I'm not sure myself where I stand on it), but I do think there's a reasonable case for both directions. Zeev
