Some clarifications before I get crucified:
> "editions" (the way I imagine) I don't want to misrepresent Nikita. His idea of editions might be completely different. > If "editions" (the way I imagine) had been introduced prior to PHP 7, we > might now have a PHP 7 engine that would still support code written for PHP > 5.x. Of course in general, most of the code "written for PHP 5.x" already works in PHP 7. Except when it doesn't. But the argument goes further. If "editions" had been around earlier, perhaps the opt-in flavor of PHP 7.n would already be more strict than it the non-opt-in flavor of PHP 7.n is now. Having the possibility to let files opt-in can allow for bolder and faster innovation, with less holding back. On Sat, 31 Aug 2019 at 03:52, Andreas Hennings <andr...@dqxtech.net> wrote: > > On Sat, 31 Aug 2019 at 03:40, Reindl Harald <h.rei...@thelounge.net> wrote: > > > > > > > > Am 30.08.19 um 20:56 schrieb Andreas Hennings: > > > In one of -these modules I initially used the ?? null coalesce operator. > > > Then I had to replace all of the instances of ?? with the more verbose > > > old-school code, to make it compatible with older PHP, because there > > > are still enough Drupal 7 installations out there which have not > > > upgraded to PHP 7 yet. > > > I also had issues with old 3rd party libraries, which stood in the way > > > of PHP version upgrade. > > > > > > In a world with "editions" per file or per package, such projects > > > could more easily use the newest PHP version, while the old libraries > > > would continue working. > > > > no, it could not, when these days installations aren't running PHP7 at > > all you won#t have support for new features > > If "editions" (the way I imagine) had been introduced prior to PHP 7, > we might now have a PHP 7 engine that would still support code written > for PHP 5.x. > > There is a limit in how far this makes sense. In a lot of cases, what > "breaks" in PHP7 was already broken to begin with. > So in a way the BC breaks can be a good thing, they force people to > fix the mistakes from the past. > > > > > you can declare what you want on top of the file - when the server is > > sloppy mainatined and running stone old software you simply can't use a > > recent feature > > > > just stop supporting such unmaintained setups and they will disappear, > > break them as hard as you can! > > > you need to distinguish two different things here: > - server infrastructure / php version. > - the actual PHP code in the project, which might be a collection of > custom code and various 3rd party packages with different age. > > upgrading the server infrastructure and php version is easy, compared > to upgrading or fixing the PHP code itself. > The only reason why people might stick with an old infrastructure and > php version is because the new version might break their legacy PHP > code. > > As said earlier, I would claim that increased BC tolerance with opt-in > strictness per file would make it more likely that people use the > latest php version available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
