Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119896
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAPyj-LAughwkC=nQjU=K56rMmCjPdmq42DPPr7Q0v0dtkieLzA@mail.gmail.com>
 <CADK1yXKWbwiUAmWpoOdCF459fzq3w47SpwBvJ_6-nXTnfzkjhQ@mail.gmail.com>
 <8abbed60-5569-4eca-ad12-957877feed9b@app.fastmail.com> <CADK1yXJj1=gfNLgUX69yED_pa5zJLJomyQ9M0K57zavu1fTikw@mail.gmail.com>
 <efa92c34-7296-44f0-b120-635a3590f8cb@app.fastmail.com>
In-Reply-To: <efa92c34-7296-44f0-b120-635a3590f8cb@app.fastmail.com>
Date: Tue, 11 Apr 2023 00:09:24 -0300
Message-ID: <CADK1yXKrxuBpScE7oWNo-dVPGi1p7wHCKRe28JhknBZxQy_B5g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b3b5b905f906d3f0"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: deleugyn@gmail.com (Deleu)

--000000000000b3b5b905f906d3f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2023 at 7:03=E2=80=AFPM Larry

>
> Again, let's assume there is no question it will happen.  The question fo=
r
> you: What process for making it happen would you consider sufficiently
> BC-friendly?  What timeline?  What level of pre-review?  What reasonable
> process would you propose that maximizes the ability of the language to
> remove its own design bugs while minimizing the hassle for responsible
> developers?  (Responsible: They actually pay attention to upcoming change=
s
> and prepare for them in less than 7 years.)
>

What I would consider sufficiently BC-friendly is having a cut-off. Any
code written by the previous generation (folks that are long gone or
retired by now) continue to work as it used to while I catch up in removing
it from production systems. If the code was written in 2010 or earlier and
uses $a++; with the expectation that it will result in "b", leave it as-is.
If the code was written in 2018 or earlier, feel free to break it.

Several discussions around this have happened, but unfortunately none
landed anywhere. Whether it be a new opening tag of <php8 or <php9 or a new
directive/edition. In fact, if we're talking about my opinion only (what
works for me personally), make this change behind the existing
strict_types=3D1. There's no "PHP 5 Era" code under my responsibility that
has strict_types enabled so if it were up to me, make every BC break you
want behind strict_types=3D1 but keep PHP with strict_types=3D0 running wit=
hout
BC breaks for about 10 years.

When PHP libraries break BC, it often comes with options of 1) extend the
original class and override something 2) opt-in to old behavior 3) register
a callback that can be used to define the old behavior back in or 4) work
with an interface or 5) last resort to fork the library if taking the
maintenance burden is worth it. I don't have any of these options when PHP
breaks BC.

Yes, old PHP has some bad and weird behaviors. I don't like it, you don't
like it, nobody likes it. I don't want to use those weird stuff, but I'm
doing the best I can to replace every single line of old code that has been
written in an era that "best practices for PHP development" were not what
you and I know today.

Take PHP 7.2 deprecation of counting non-countable arguments. Could that
broken code have been taken out of PHP Core, made it available as a legacy
PHP extension and just kept alive for the foreseeable future? Can we have
an additional PHP extension that allows us to still pass null to
non-nullable internal function parameters? Something like php56_substr().

I don't mind if its BC breaks are opt-in or opt-out as long as we can have
a single cut-off and make it easier for us to keep running legacy code
until we succeed in decommissioning it.

In fact, if you wanted to deprecate `readonly` in PHP 8.3 because (as
you've said it), it's a broken behavior that prevents you to move forward
with asymmetric visibility or property accessors, I wouldn't care because
readonly was something introduced in a time that the code being written
using it has 100% test coverage and static analysers protecting it. It's
easier for me to deal with any BC breaks of PHP 7.1 or higher than it is to
deal with deprecations of PHP 5.6 or lower.

--000000000000b3b5b905f906d3f0--