Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120355 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68169 invoked from network); 19 May 2023 03:52:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 May 2023 03:52:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D5DE8180209 for ; Thu, 18 May 2023 20:52:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 18 May 2023 20:52:09 -0700 (PDT) Received: from oxbsltgw00.schlund.de ([172.19.249.17]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MJEIl-1pk7Yh12Hj-00KfHC for ; Fri, 19 May 2023 05:52:08 +0200 Date: Fri, 19 May 2023 05:52:08 +0200 (CEST) To: internals@lists.php.net Message-ID: <1057417071.3160630.1684468328127@email.ionos.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev43 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:YlAgYX8WIF86rF5Zp+D3GDYK3FGp1aYdWes1FpDTl09FUkd1i75 8l50pgvVjmnCG57mM3kuIb7coTeUP/ZATbyogLvyREvv/mQnvat885pmRKK8YHb+p3vUqjb LjSgl31ZL2FgJjbGS6O/IkA7q36EWCpwSbYzYLrcvkavtSuAXOYg9qytQz+uV/f5AEVACWx TMkbNxTQ+5AqE+gTiwwQg== UI-OutboundReport: notjunk:1;M01:P0:VorPNDBK40o=;ouE09P7kLunBw3rRDfLwnn/REgP XG/e2KuQsxR7ZQZ0iQPzid6vVeAWucDy8opSprNK5KiT3YmzvANegctaTxn2I8nrVzDaB3F/A ezaCgmtQbmtT6PDdd8lmg77MS+Rk0LwDVtmhLOsmvRSTQ1e0E3eqBHU7MNnxRZJKItJJVZoAe U4pmoTOPBEG2CJCrbkjX5QOBsbqdIH7c1NLFsfK8Ng2mRiQWhnBA4FVF8rEwcAHNs0Hbu+zji QGiZunnd5B8gBZy9g0apDVerp2b/H33IX5yjq9cBjQwO78v/Wwwr5xFYDeDY0d9gYwLnd7CHh lAPrpY/Su++RBnHTcfA4F29LU4iCKwhEhOPzSF5hdwdnnq9IB/q+Jov13Mdta1aa/Ux1iiHbu F9J4UpcUieGijvIj4b1vaVof16+zjqq5QdX/XLm+k2baSnYxd/WtR6saZ+PqZ+R4w3nLXy+0L kx/GDYNzKET9Tys+bII4/Whf2MsMJ49m8rZWPoQlaPOVZ3f1oZ3QCFynrv0Pt6nIs3+PwF1P3 xK4BX+kay6w/iCPSj1b7zp2rGuiMNnA8aoOnPQ2QegauAxkgY4uisiOMTqABmvvBwd+/0hkbn Ve/26UtiQ4zl42pLDEyGejBzhU0LP4HlnBTpFTHvn2KDRX8oAUW+/YMwmj/ncXAp0BF3GB33Y aT8MCtAYcDyFvKmFr53y Subject: Re: [PHP-DEV] PHP 8 Backward Incompatible Change Notifications From: mails@thomasbley.de (Thomas Bley) Hi Alan, regarding "String to Number Comparison", you can cast the value to int to get the old behaviour: php -r "var_dump(0 == (int) '0');" php -r "var_dump(0 == (int) '0.0');" php -r "var_dump(0 == (int) 'foo');" php -r "var_dump(0 == (int) '');" php -r "var_dump(42 == (int) ' 42');" php -r "var_dump(42 == (int) '42foo');" gives: bool(true) bool(true) bool(true) bool(true) bool(true) bool(true) Best Regards Thomas > Alan Smithee hat am 18.05.2023 23:34 CEST geschrieben: > > > Hi Internals! > > Looking for counsel from the PHP maintainers here regarding the upgrade > path from PHP v7 to v8. > > There is a subset of backward incompatible language changes that are > remarkably tricky to track back into a codebase through manual code > inspection, automated testing, or static analysis (...I'd love to be > proven wrong here). The behavior change in these cases are triggered by > data passed into functions or operators at runtime, such as "String to > Number Comparison" [1]. > > Using this example, in a large-enough (and legacy-enough) codebase for a > data-driven application where there is a cost to every change, I am > struggling to find an effective mechanism for targeting the set of all > equality comparisons in the codebase that could potentially operate on a > pair of number/string operands. > > I've found that the most effective mechanism that has helped me to > quickly and comprehensively identify areas of code at highest risk for > the upgrade has been deprecation and warning notifications provided by > the PHP language regarding backward incompatible changes. > > To this end, I'm considering patching the current version of the > language I use, i.e. v7.4.24, for my own benefit and introducing more > notifications for the handful of highest-risk, backward incompatible > changes not currently reported by PHP. > > I see Nikita Popov has already done something along these lines [2] for > the "String to Number Comparison" change mentioned above. > > My questions for the group: > > 1. Are there any particular reason(s) why some PHP 8 backward > incompatible changes, like "String to Number Comparison", weren't > instrumented as deprecation or warning notifications in PHP 7? > 2. Are there simpler or more effective strategies to account for the > set of backward incompatible changes I've called out given the > constraint of a large, legacy codebase? > > [1] > https://www.php.net/manual/en/migration80.incompatible.php#migration80.incompatible.core.string-number-comparision > [2] https://github.com/php/php-src/pull/3917 > > Thanks in advance for any insight or advice anyone may be able to offer! > > -- > ALAN SMITHEE > Software Engineer | Five Color Team > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php