Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.208.52 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAJHtznzVSPLLvGJW471GoKbBE7uB5oLYJ+8Lq-=vYSP-LHeYww@mail.gmail.com>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAESVnVpcd7xBB+A+6Kz0b5JqnPaZfQitWLtXi-4_cZA8kf2knw@mail.gmail.com> <CAJHtznzVSPLLvGJW471GoKbBE7uB5oLYJ+8Lq-=vYSP-LHeYww@mail.gmail.com>
Date: Mon, 25 Jun 2018 11:16:31 -0500
Message-ID: <CAESVnVpC8KyHP4rOm=Ne_MfOC2Nr_jB_RKUKDDAkFdbTggeV3Q@mail.gmail.com>
To: Zeev Suraski <vsuraski@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 2^3
From: pollita@php.net (Sara Golemon)

On Mon, Jun 25, 2018 at 9:58 AM, Zeev Suraski <vsuraski@gmail.com> wrote:
> Note that I did propose that we actually have a thin depredations-only PH=
P
> 7.4 (to give credit where credit's due, that's Dmitry's idea).  This give=
s
> 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 w=
ork
> 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 2=
019
> 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 a=
nd
> 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 t=
o
> 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 thin=
g
> 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 timel=
ine
> for us to successfully deliver it than the standard yearly cadence (as wa=
s
> 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 betw=
een
> 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? =C2=AF\_(=E3=83=84)_/=C2=AF

-Sara