I don't want to say that everything in old code bases makes sense, I just want to say that mixing null and empty string was quite common in the past, mostly coming from accessing undefined array keys. PHP has always been good to create new business value quickly. The problem now is that bringing all code into new standards does not bring new business value, so companies try to delay or refuse the upgrades as long as possible (also thanks to docker and others). Also many developers don't like upgrading code since it's either too boring or too challenging. The first thing done is mostly silencing deprecation messages, which makes the gap bigger when upgrading to the next major version. So having support for multiple php versions inside one binary would be a great thing, same as modern web browsers still support html 4 even though html 5 is out for so many years.
Regards Thomas > Tim Düsterhus <t...@bastelstu.be> hat am 10.04.2023 16:48 CEST geschrieben: > > > Hi > > On 4/10/23 16:37, Thomas Bley wrote: > > Regarding compatibility promise, I'd also like to mention that things are > > quite complex now, e.g. > > > > https://3v4l.org/VfAr4 > > > > has 4 different outputs between php 7.x and 8.x. From userland perspective, > > having <?php8 or <?php9 would make things a lot easier and more productive. > > No, it has two different outputs, one for PHP 7, one for PHP 8. > > It also has two different deprecation notices, one concerning the > behavioral change between PHP 7 and PHP 8 we're seeing and one > concerning an upcoming behavioral change with PHP 9. > > However in all PHP versions the function call clearly is non-sense, > because 'null' clearly cannot be a substring of a string, as it is a > completely unrelated data type. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
