Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102419
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.47 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
Date: Mon, 25 Jun 2018 09:27:07 -0500
Message-ID: <CAESVnVpcd7xBB+A+6Kz0b5JqnPaZfQitWLtXi-4_cZA8kf2knw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: 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 7:30 AM, Zeev Suraski <zeev@zend.com> wrote:
> As I mentioned a few days ago I intended to send it slightly later - but =
as Nikita brought up the topic of PHP 8, this is probably as good a time as=
 any to start the discussion.
>
> Please note:  The goal of this email isn't to discuss in detail each and =
every topic that's mentioned, but rather to establish whether we want to mo=
ve to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research=
 projects and PoCs we've been working on.
>
With the above paragraph in mind, I would say yes; This laundry list
sounds like major bump worthy items.  However I'm going to throw some
negatives in here and probably start longer threads separately on my
concerns with specific items.

1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
7.3 which is already in fire-hose mode of last-minute, under-planned
"hey I want this toy" requests.  Yes, deprecations are a little bit
more sweaty ice cube in terms of late deprecations being lower risk
that late additions, but it's still turning into a rushed thing during
a season when some folks are off on holiday break.  The FF is in
Summer in part *because* this is a bad time to introduce RFCs.

2/ In several of theses cases we're talking about something that's not
even fully scoped out yet.  Async, for example, "requires a lot more
research".  Yes, that research can probably be completed and turned
into an implementation in the 1.5 years we have till the Nov 2019 GA
(whatever version that ends up being), but there are multiple items on
this list which are not (seemingly) fully fleshed out.

3/ When I read phrases like "open the door for new types of workloads
for PHP (non Web)", and "one of the key reasons Node is gaining
popularity", and " 'bleeding edge' technologies, such as AI and
Machine Learning" I smell a trend of chasing the new hotness and
worrying about factors other than making PHP the best language for the
Web.  Growing PHP is great, and evolving it into new areas is also
potentially quite good, but we *have* history showing what happens
when we come up with something new to chase after that then turns out
to be underwhelming, undermaintained, and underutilized.  I've also
seen what a JIT does in terms of additional complexity, it's not
pretty.

4/ When the $(%* did we body swap, because it's not quite full
turnabout, but I'm suddenly having flashbacks of "give the language a
rest". :)


Please don't construe this response as entirely negative.  As I said
in other replies, I'm actually quite excited about these new things
and the directions they open up, and it may be that you and Dimitri
have been spending quite a lot of time thinking about them and their
implications to the language going forward.  However, like the NG
branch prior to 7.0, most of this appears to lack any sort of plan for
those of us not in your private email threads.  Yes, we've discussed
all of them at one point or another, but apart from the JIT, there's
been no obvious signs of work on any of them, which brings me back to
being concerned about 7.3 suddenly being flagged as the last 7.x
release within mere DAYS of its planned feature freeze branch date
without warning.

Possible alternative.  Still aim for Nov 2019 GA of 8.0, but have a
7.4 in parallel with it.  This (sort of) happened with 4.4 being
released between 5.0 and 5.1 (I know, not quite the same).  This would
give us a couple advantages:

1/ Take our time with these last-minute "deprecate all the things"
RFCs that have suddenly popped up.
2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations
for the big stuff aren't quite ready for whatever reason rather than
being forced to push them to 9.0

Downsides, obvious: More merges for bugfixes and RM overhead, plus
Remi and Stephen's time with Fedora/Win32 builds.  We did this for the
5.x-7.x jump, I say we can do it here.

-Sara