Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:119855 php.internals:119856
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5BF26CFC-9E5C-473D-A0FF-CEFD98B55669"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Date: Mon, 10 Apr 2023 13:58:58 +0100
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAGBsUrcQWKc+JD2adprcgdqNAKr==McFeoYO3WF3pR2qxgon2g@mail.gmail.com>
 <CAMXcktN64EsoErjbFzdWe+qzM5RVYNR98WO8xcLOYxeYCK=NiA@mail.gmail.com>
 <CADK1yXJMgSrjCahW2_G-C=ye=mBiuWtQAKyJrbFc-W4ODL6fZw@mail.gmail.com>
 <CAGBsUrd=X6d8eZsSjaz+hQYLTCPCHPExhsawWhr8BWD=prEb1Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAGBsUrd=X6d8eZsSjaz+hQYLTCPCHPExhsawWhr8BWD=prEb1Q@mail.gmail.com>
Message-ID: <E1957E21-F069-4E78-98F1-DAF14EE3D92E@craigfrancis.co.uk>
Subject: Re: [PHP-DEV] Future stability of PHP?
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_5BF26CFC-9E5C-473D-A0FF-CEFD98B55669
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 9 Apr 2023, at 23:10, Kamil Tekiela <tekiela246@gmail.com> wrote:
> I wonder about this every time I hear this claim. What exactly changed =
in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 =
may be a little more difficult because of some of the recent =
deprecations, but that's still years ahead of us.



Most of the deprecations and changes do make sense, and while =
deprecating dynamic properties is going to be a pain, I think it's going =
to be worth it (like undefined variables), same with ${} string =
interpolation (better to be consistent); and I know it's been mentioned =
in this thread, but `utf8_decode` does get misused a lot (read the RFC =
as to why).

But I do not understand "Passing null to parameter # of type string is =
deprecated" specifically.

I should note that the other coercion/type tweaks that G.B.P (Girgias) =
is suggesting, and has partially implemented, do make sense:

https://github.com/Girgias/unify-typing-modes-rfc

And (fortunately) NULL coercion still works when concatenating NULL to a =
string, adding NULL to an integer, NULL being treated as false, etc.

One team of developers I know are still finding these issues well over a =
year later (they also introduce new code that trips it as well); two =
other teams specifically ignore this deprecation (far too many instances =
to "fix"), and one team is still to decide what they are going to do =
(annoyingly they are still using 7.4).

Even Rector gives up and uses `(string) $var` for every variable that's =
a non-nullable string, which can result in thousands of changes in a =
project (that's for the ~434 function arguments being checked; =
personally I'd have only gone with 335 of the ~997):

=
https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncC=
all/NullToStrictStringFuncCallArgRector.php

Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that =
isn't using strict types, that's going to cause lots of random and =
unexpected problems.

Craig



PS: I drafted this RFC, but didn't continue due to the negativity (i.e. =
it would have been voted down, and then used to justify the type error):

https://wiki.php.net/rfc/null_coercion_consistency


--Apple-Mail=_5BF26CFC-9E5C-473D-A0FF-CEFD98B55669--