[MH15]

I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

[tored]

I work on multiple projects from PHP 5.2 to PHP 8.3 and everything in between.

Statistics based on packagist(composer)

https://stitcher.io/blog/php-version-stats-january-2024

Statistics based on web servers in the wild

https://w3techs.com/technologies/details/pl-php

https://w3techs.com/technologies/history_details/pl-php

[post_below]

PHP 5 is as close to phased out as it gets at this point. No doubt it's still in a lot of legacy enterprise codebases (lots of breaking changes going from 5 to 7 or 8), but outside of that no one is using it.

[zuppy]

php 7 has been released 9 years ago.

[noduerme]

Yeah, and I just finished porting an enormous amount of production code from PHP 5 to 7.x before fully moving it to 8. There are so many breaking changes in each major version, when you have a lot of live projects and clients don't have the budget to pay you to upgrade them, they can lay stagnant for years until way past EOL. It would have been nice to know, for instance, that future versions of PHP would throw warnings about undeclared variables or unaccessible named properties of "arrays" - which could previously be relied upon to be false-ish. That's a major pain point in code bases that treated arrays as simply dynamic objects that could be checked or defined at will. Lots of isset() and !empty() and other BS. Fine, but it takes time to sit down and check it all. I really preferred it when it let you just screw up or try to access a null property or define a variable inside a block and access it later without throwing any errors at all. Nothing about its actual functionality has changed in that regard; it's just errors you have to suppress or be more verbose to get around. In PHP 8 you can still do this:

`if ($a) { $previouslyUndefined = 2; } if ($previouslyUndefined) { echo "yeah"; }`

PHP still knows what $previouslyUndefined is or isn't at the second if statement, but it'll throw an error now in the first statement if you hadn't declared it outside the block. Why? Who cares? Scope in PHP is still understood to be inline, not in block; there is no equivalent to let vs var in JS. Stop telling me where I can check a variable if you're not enforcing various kinds of scope.

[zerocrates]

Your $previouslyUndefined thing as something that's changed, as far as I know, isn't true? Unless I've missed some very recent change.

If $a is true, that snippet will just execute with no errors. If $a is false you'll get a warning trying to check $previouslyUndefined in the second if. That behavior's been the same for a very long time. The blocks don't matter for scope but the fact that you never executed the line that would have defined the variable does.

Similarly, warnings on accessing array keys that don't exist, that's been a thing forever too. Pretty sure both go back with the same behavior to PHP 4, and probably earlier.

[asddubs]

>Why? Who cares?

I do, if I typoed previouslyUndefined the first time. I get it adds boilerplate, but it also catches stupid bugs

[reddalo]

The Laravel ecosystem folks seem to be always up to date in recent PHP developments. At least, that's my impression.

[chx]

Drupal is very hot on attributes, has fiber support, uses readonly (a PHP 8.2 feature) extensively, enums are used -- overall it's fairly up to date.

[naiv]

Symfony also does a great job adding polyfills way ahead of a PHP release , eg https://github.com/symfony/polyfill-php84

[withinboredom]

Yes, and this is incredibly annoying. Many packages add them as a dependency, and then you get subtle bugs because of it. Or worse, they add a dependency for the polyfill that is related to an extension and suffer performance issues when the extensions are not installed; yet no warning is output.