Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102445
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
To: "'Larry Garfield'" <larry@garfieldtech.com>
Cc: <internals@lists.php.net>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com> <4719624.u8nS1KoLlB@vulcan> <CAJHtznzPE88XzvwPYArstyuF2mMKE6G7yP7Lp=yo4E4GYuidVw@mail.gmail.com> <28344669.tbARPPRcEQ@vulcan>
In-Reply-To: <28344669.tbARPPRcEQ@vulcan>
Date: Tue, 26 Jun 2018 00:29:12 +0300
Message-ID: <013e01d40ccb$90bf0840$b23d18c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQILbU8xMaAgsSO0vKBUv7rveEtyLQHYi9NkAZzAhLYA3tNpraPgFNEA
Content-Language: he
Subject: RE: [PHP-DEV] PHP 2^3
From: vsuraski@gmail.com ("Zeev Suraski")

> -----Original Message-----
> From: Larry Garfield [mailto:larry@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