Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120047
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6
Mime-Version: 1.0
Message-ID: <e1f5c064-3328-46c9-9621-4f8d5795dad8@app.fastmail.com>
In-Reply-To: 
 <CADK1yXKrxuBpScE7oWNo-dVPGi1p7wHCKRe28JhknBZxQy_B5g@mail.gmail.com>
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>
 <CADK1yXKrxuBpScE7oWNo-dVPGi1p7wHCKRe28JhknBZxQy_B5g@mail.gmail.com>
Date: Sun, 16 Apr 2023 22:35:12 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Future stability of PHP?
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Apr 10, 2023, at 10:09 PM, Deleu wrote:
> On Mon, Apr 10, 2023 at 7:03=E2=80=AFPM Larry
>
>>
>> Again, let's assume there is no question it will happen.  The questio=
n for
>> you: What process for making it happen would you consider sufficiently
>> BC-friendly?  What timeline?  What level of pre-review?  What reasona=
ble
>> 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 ch=
anges
>> 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 rem=
oving
> 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 a=
s-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 (wh=
at
> 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 y=
ou
> want behind strict_types=3D1 but keep PHP with strict_types=3D0 runnin=
g without
> 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) reg=
ister
> a callback that can be used to define the old behavior back in or 4) w=
ork
> 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 do=
n'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 w=
hat
> you and I know today.
>
> Take PHP 7.2 deprecation of counting non-countable arguments. Could th=
at
> broken code have been taken out of PHP Core, made it available as a le=
gacy
> PHP extension and just kept alive for the foreseeable future? Can we h=
ave
> 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 forw=
ard
> with asymmetric visibility or property accessors, I wouldn't care beca=
use
> 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.

Thank you, now that's a proposal that we can actually discuss.

That said, I don't think that strategy would be viable, for a couple of =
reasons.

1) It assumes a strong correlation between "code was written in <2010" a=
nd "the QA process is crap", and likewise between "code was written >201=
0" and "the QA process is pretty solid."  I strongly suspect that correl=
ation is a lot weaker than you make it out to be.  The really-old public=
 projects I know (I've worked on Drupal and TYPO3 cores personally, both=
 of which are 20+ year old code bases) have pretty solid test coverage n=
ow, and ample QA processes around them.  They're possibly tedious to upd=
ate for deprecations et al, but not per se hard.  In contrast, I now wor=
k with some 7.x-era Laravel projects that, well, "get the QA tooling out=
 of the stone age" was the first task I took on when I joined the compan=
y because they desperately needed it.  I don't think "it's newer so the =
QA safety net is in place" is a safe assumption.

2) The vast majority of issues that need to be fixed are the old stuff; =
most are from PHP 4 or PHP 3, so we're talking pre-2005.  The features i=
ntroduced from 5.3 onward are, for the most part, pretty reasonable.  (N=
ot perfect, but way way better than the PHP 3-era stuff.)  So "you can o=
nly clean up recent messes" translates to "you can never clean up a mess=
."

3) There can absolutely be code written in 2020 that relies on the curre=
nt behavior of array_sum, or $string++, or passing null to strlen().  So=
me of it has been mentioned in this thread.  So "only old code relies on=
 old, bad language design decisions" is not really a safe statement, eit=
her.  We could say "well those devs should have known better," but... in=
 most cases the code from 2005-2010 was also written by devs who "should=
 have known better," as many of these issues were known-problematic even=
 then.  (Dynamic properties, for instance, have been not-recommended sin=
ce at least 5.2, if not earlier.)

4) It doesn't answer the question of when it *is* OK to start fixing the=
 old issues.  "When I'm done cleaning up the mess I inherited" is not a =
metric that Internals can really work with, but locking in "bad design d=
ecisions from before 2010 are locked in forever, just in case, but we ca=
n correct stuff after that without warning" is not really sustainable.

5) Different running "modes" have been discussed several times.  Usually=
 they come back to "if we were to do it, declare statements are the best=
 mechanism."  But they also almost always run into "every declare statem=
ent means we have to add a bunch of conditionals in the engine or stdlib=
 to check it, which is a lot of complexity to maintain."  And those are =
multiplicative, so if, eg, we added declare(allow_dyn_props=3D1), declar=
e(allow_null_string=3D1), and declare(modern_numeric_strings=3D1), in ad=
dition to the existing strict_types, that's 2*2*2*2 =3D 16 possible comb=
inations of run modes.  Regardless of what the default values are, just =
thinking about the number of test cases that would need to be written fo=
r that makes me sweat.  And that's before we even get into bifurcating P=
HP into multiple incompatible rulesets that make it hard for anyone to e=
ven learn how to use PHP.

If you want to polyfill old core stdlib function behavior, there might b=
e a way to be extra tricksy with namespaces and autoloading (if that pas=
ses) to make something work, but that sounds unreliable.  The real answe=
r here would be the old runkit extension, but most people who know of th=
at are afraid of it, because they know exactly how much confusion that c=
ould cause. ;-) =20

If the stdlib were written in PHP, not C, as has been suggested a few ti=
mes, that might open up other options.  I've not thought that through en=
tirely.  That's still not at the point that it wouldn't have a performan=
ce impact to do, though, which is why there's been no serious attempt at=
 it.

--Larry Garfield