Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102435
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
Date: Mon, 25 Jun 2018 12:51:53 -0500
Message-ID: <4719624.u8nS1KoLlB@vulcan>
In-Reply-To: <CAESVnVpC8KyHP4rOm=Ne_MfOC2Nr_jB_RKUKDDAkFdbTggeV3Q@mail.gmail.com>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com> <CAJHtznzVSPLLvGJW471GoKbBE7uB5oLYJ+8Lq-=vYSP-LHeYww@mail.gmail.com> <CAESVnVpC8KyHP4rOm=Ne_MfOC2Nr_jB_RKUKDDAkFdbTggeV3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart49365286.mFQPGTkMgi"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] PHP 2^3
From: larry@garfieldtech.com (Larry Garfield)

--nextPart49365286.mFQPGTkMgi
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote:

> > 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.
>=20
> 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.

When we speak of "typical web loads" not getting much benefit here, are we=
=20
really talking about CGI-style "reboot every request" type loads rather tha=
n=20
"IO-bound work"?  Because it's been observed many times in the past that on=
e=20
of the most expensive parts of a modern PHP app is simply booting up,=20
initializing all of the services, wiring everything together... and then=20
throwing it away 100 ms later.  If a JIT would make it more viable to pre-
start a web process (there are various all-user-space implementations in th=
e=20
wild already) so that an incoming request already had a fully booted system=
=20
with container initialized and stuff, that could have a huge impact on web=
=20
loads, even without going all-in on Node-style async.

(I am, of course, possibly talking out of my butt here.  Please advise if s=
o.)

> > 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.
>=20
> 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
>=20
> -Sara

Question from the peanut gallery: why would 7.4 need to be a deprecation-
mostly release?  Is the concern that it would make merging to the engine=20
changes in 8.0 harder?  Something else?  I guess I'm missing why a 7.4 that=
=20
adds warnings about "stop doing this now so your code works in 8" would=20
conflict with a 7.4 that also adds whatever routine functionality or=20
improvements get developed in the meantime.  (Typed properties or otherwise=
=2E)

Historical note: If we view PHP 5.3 as PHP 6 (which it was in any meaningfu=
l=20
sense), then PHP's had a remarkably consistent ~5 year run for each major=20
version for quite some time now.  That would put November 2020 as the natur=
al,=20
expected release date for 8.0, which especially if it's signaled now would=
=20
give everyone ample time to prepare and expect it right on schedule.

Also, while uptake of new PHP versions is still way slower than the release=
 of=20
new PHP versions, at least based on the Composer data that Jordi releases i=
t's=20
getting steadily better over time.  The reasons for that are likely complex=
=20
but we're a long long way from the days when the GoPHP5 project was needed.=
=20
:-)  (And good riddance to those days.)

=2D-Larry Garfield
--nextPart49365286.mFQPGTkMgi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlsxK7kACgkQ4MMKwDFx
YXdv2Af/fJVBbXkD6gJtBHmVZ+AMFcNagdccBahS6dtysNyuSNWxgG+2fBUoCaj4
9ixFHaRKmCQyE6oDi6bKCJwPqqLfq3s7uopa5FqquqhNgHC+3yd+RB+iZssiskk/
wleZGr0NVeZBtx+u1pBgxMUT9JJCJ3O7F3yGEnVG4/3KtZFes/picHdH890Z5tTk
dnbPtSP+EHZuTA+qniF2pZF+C53o9Hu6sDQ4539j5t0sGSuq0hykU0O4rV+au014
nuRaFmxYvEwYH3TamWhzwK/ZSRSGgxj99+YyCEAa5h8cqEQIRf+sDvGKZ3j8T4b6
m77CXinxivI4MgNh5VeQKB03FboMzQ==
=CTA8
-----END PGP SIGNATURE-----

--nextPart49365286.mFQPGTkMgi--