Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106540
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=CSMfAoBwCGDRVZcwOc89Ug9vY5XRXruIy+I0Ui6ZWIz69pm5gfeFhG71knfTXb
	3hITjVDbxR/wA8cTnehiLf8ERpf+XtcKPA9qGIcpdwZ/Z9pHaJhOF5xxDAkKSU7L
	JQFtSAF9qTXxbt78ak4JMVxO3jrCNtQjcSXb+TlJud9F8=;
MIME-Version: 1.0
References: <CAJHtznw0eKbBNJo9TnDwZvvbMMFt5mCo=+SpKLw0zYzq9tKWZA@mail.gmail.com> <5d4e9052.1c69fb81.471c4.1224SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5d4e9052.1c69fb81.471c4.1224SMTPIN_ADDED_MISSING@mx.google.com>
Date: Sun, 11 Aug 2019 12:41:33 +0300
Message-ID: <CAJHtznwo1TtWPv+bvrV-=AKpk4M9eq_sUJnFV1DX-Rx-50VnVg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001819c8058fd437c1"
Subject: Re: [PHP-DEV] Re: P++: FAQ
From: zeev@php.net (Zeev Suraski)

--0000000000001819c8058fd437c1
Content-Type: text/plain; charset="UTF-8"

On Sat, Aug 10, 2019 at 12:37 PM Andrea Faulds <ajf@ajf.me> wrote:

> Hi Zeev,
>
> As the person who initially proposed and implemented strict_types, I
> think this is heading in the wrong direction. Perhaps that directive was
> a mistake, if it will lead to so many attempts inspired by it to
> fragment the language, including this one. Personally, I don't actually
> want a language like C++ or Java. PHP's flexibility is great, and I
> think splitting the language means going in a direction where you are
> forced to have everything be strict or nothing be. PHP++ sounds like
> Hack, but in mainline. I think it'll end up a mess in the long term.
>

Hi Andrea,

I really appreciate your point of view on this.  I'd love to better
understand what you think we should do when translating this point of view
into action.

Specifically - if we go in the direction of Editions, which - as far as I
can tell - has the potential to split the userbase (de-facto) at least as
much if not more - would you see this as a bad direction?

Nikita pointed out that there are several strategies to introduce
compatibility-breaking elements.  The precedent that we introduced with
strict_types, is to provide granular control at the feature level.
Granted, we only did one of those so far - but it's of course a possibility
to go on adding additional ones (such as strict_variable_declaration,
strict_ops, etc.).
The other option proposed is to have editions - which are collections of
such changes, that come as a unified package - you can't pick and choose
what you like or dislike, it's all or nothing
The 3rd option that I proposed, is to have the equivalent of just two
editions - we could call them 'classic' and 'strict' - that like editions,
users will be able to choose from on a per-file or per-package basis.

I *think* most of us will agree that option #1 isn't a very good one.  It's
by far the most flexible one - but it's also the messiest one.  It's also
arguably more complex to maintain, as you have to make sure each feature is
conceptually consistent with each other feature in both of its mode
(on/off), and also that each feature actually *works* with the other
feature in both of its modes in terms of implementation, if there's any
interaction between the two.

I think most folks would agree that Editions is a superior idea.  You group
several changes together, and you have a new, consistent dialect of the
language that users can opt into.  It's by definition a lot less flexible,
but flexibility isn't always a good thing.  It's easier to maintain, easier
to explain, provides fewer permutations of testing need to happen - and
reduces the cognitive load when reading code.  In terms of what we
sacrifice - we don't sacrifice much - because as we come to evaluate the
wants and needs of the userbase - it seems that the same folks that would
want strict_types, would be the ones that want strict_ops and
strict_variable_declarations.

In my mind, Editions -> per-feature-control is similar to P++ -> Editions:
- It's less flexible, but much like that's not a negative thing with
Editions - it's not a negative thing here either.  We won't have to support
PHP2020 in a version that we'd release in 2023.  Someone committing to P++
will be getting the new features (and compatibility changes) as they
upgrade - precisely as folks who upgrade PHP today do, without having to
(or being able to for that matter) opt-in or out.  The motivation that
everyone has to keep current (for stability/security reasons) will continue
to be a driving force for folks to take the trouble to upgrade.  They'd
have the ~2 years of maintenance time of the previous version to take the
time to upgrade - but over a long enough timescale, we'd have just two
flavors - not N.
- Psychologically, it allows us to introduce more compatibility breaks from
the get-go - instead of rolling them out gradually over time.  That is also
a good thing.  Much like PHP 5 (that introduced a completely different
object model) kickstarted the development of brand new frameworks (Symfony,
Zend Framework, others) - I'd expect there to be P++ frameworks that would
spring to life.  It's a lot more sensible to give them solid grounds upon
which they can build the framework (or app) - and not tell them that them
that if they'd want to keep current in 2025 - they'd be likely to have to
roll out another rewrite.
- Vision-wise, it allows us to lay out a clear, consistent vision for P++,
and say how we think it will differ from PHP.  We don't have to deliver on
it right away - it will still be helpful to users to know what they should
expect from PHP, what they should expect from P++  - and allow them to
choose which one to focus on.  It'll also help us in internals@ discussions
- it'll usually be fairly clear what goes where - making discussions a lot
less contentious.
- Marketing-wise, it has clear advantages, even if many folks here don't
want to evaluate that angle.

P++ is not radically different from the Editions idea.  It's quite similar,
with a different roll-out strategy - and it opts to make a clear statement
on the long term viability of dynamic PHP.

Regarding splitting the userbase - I think we need to face reality.  Our
userbase is already soft-split, and as we introduce more and more
optional-strict elements - this soft-split will grow larger (although I
still think it'll remain soft - I don't think it'll descent into an "us vs.
them" level).  Since we're considering the introduction of more and more
compatibility-breaking ever-stricter changes as a given (so many, in fact,
that the key implementation challenge with P++ appears to be our ability to
deliver all of them in a reasonable 2-3 year timeframe (!)) - we need to
ask ourselves what that would mean in practice.  It's clear that at least
for some folks - that means that the language gradually evolves in that
direction - slowly but surely leaving its dynamic nature behind and
allowing it (or forcing it) to die.  I'm hoping that the vast majority of
folks here understand that this isn't a viable option, and I think we need
to send a clear message to everyone (particularly the pro-dynamic crowd)
that this isn't in store for them.  At the same time, we need to figure out
how we are going to manage the growing distance between dynamic PHP and the
new one that we're working to create.

If we insist on keeping our language unified as we introduce these changes
- do you see a way to do that that is not a zero-sum game?

Thanks again for your feedback,

Zeev

--0000000000001819c8058fd437c1--