return self::CONSTANT; // Fatal error
however that is actually allowed, what is an fatal error is
return Foo::CONSTANT; // Fatal error
compare
https://3v4l.org/dIeOk#v8.2rc7
https://3v4l.org/11of1#v8.2rc7
Prohibit direct access through a trait name
[1]: https://wiki.php.net/rfc/deprecate_dollar_brace_string_inter...
PHP supported versions - https://www.php.net/supported-versions.php
Maybe read https://stitcher.io posts about the new features since 8.0 to have a grasp of the language changes.
Python 2 -> 3 change really was painful for Python community, but PHP does these almost fundamental breaking changes so often, that maybe people just get used to it? I haven't really followed Python past version 2, but I think they are less likely to ever do such amount of breaking changes.
There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
Edit: Those dogpiling there, I rest my case with josefresco's comment:
https://news.ycombinator.com/item?id=33907628
It's painful. Dropping dynamic properties? That will be a lot of fun. WordPress is probably biggest segment for PHP usage.
EDIT: have you looked at ngx-php. It’s blazing fast and provides you that event loop.
So there's some argument to be made to be in the 8.x series. It's probably not something you should be losing sleep over just yet, but at least have it on your roadmap to address in the coming months.
PHP 8 is in "beta support" currently, but that's just Core. A lot of plugin developers are lightyears behind it seems:
https://make.wordpress.org/core/handbook/references/php-comp...
Yes it's a userland workaround and not a fix for the language, but it's thinking about these issues and a PHP extension (offering better performance) is being talked about.
The no-brainers to me are the missing array_some()/array_any() array_every()/array_all() and an array_search() that takes a predicate and iterable. I do these now in userland but an optimized native version would be nice.
A lot of cPanel or similar hosts are also retiring old versions as they hit EOL [1][2][3][4][5] (those all support 7.4 still but most have indicated that will be dropped next year as well). This has made hosting transfers more and more difficult if you don't want to go through the process of upgrading.
The process of upgrading Wordpress sites isn't so bad (generally there's no work, honestly). But not all CMSs are that simple and it can get more laborious when you want to upgrade a Laravel or Symfony site, especially if you've skipped a few versions.
Of course, at the end of the day, it's up to the client to provide budget for these things and if they don't/can't, you just have to push back on their other requests until they do.
1: https://in.godaddy.com/help/retiring-old-php-versions-41164 2: https://www.bluehost.com/hosting/help/php-version-selection-... 3: https://help.dreamhost.com/hc/en-us/articles/215082337-What-... 4: https://wpengine.com/support/php-guide/ 5: https://getflywheel.com/wordpress-support/php-on-flywheel/#p...
I hate language-specific package managers. I can see their value to packagers (less work), but they end up arguing with the platform package manager.
It's like there's a load of CS graduates churning out lots of new, better languages; but what's really needed is just one better language. Similarly we have a score of new package managers, creating incompatibilities; so we add some more package managers, to paper over the incompatibilities.
I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
https://www.reddit.com/r/linux/comments/nnxng/petition_lenna...
Moving from 7.4 -> 8.2 will be just as much refactoring as moving from 7.4->8.0->8.1->8.2. Security support is in general three years [0] so everything 7.X is now unsupported. Considering the security cadence you can skip one version, but if you skip two you'll probably be out of security support before you migrate to a new version. My philosophy is if you're going to need to do the work to upgrade anyway, you might as well do smaller chunks more frequently and be able to take advantage of the language goodies that come out earlier.
The amount of the language that gets deprecated every year is PHP's fundamental flaw, at least in the last five years.
https://www.php.net/supported-versions.php
I know the web needs constant maintenance, but I wish it wasn't so much. PHP has been pretty good about not breaking changes, but I've noticed a few..
PHP is my goto. Its pretty great. It enabled a startup I was part of to get off the ground.
But PHP 7.4 is not compatible in many ways with PHP 7.3, so lumping them together is not OK. As you can see, PHP 8.0 which was only released two years ago, is no longer receiving active support. Definitely, database LTS is not comparable to programming languages. However such rapid releases of breaking versions is a relatively new phenomenon (thanks NodeJS), and I get the feeling that you've never actually supported a software project for 5+ years.
[0]https://www.cloudways.com/blog/wordpress-performance-on-php-...