| > The wordpress integration test suite broke with PHP 8.0. Wordpress was since it creation a bad coded software and as a result they have issues with keeping up with the php release cycle. > In the near future you won't be able to assign new properties on instantiated objects anymore. Wrong, the stdClass that json_decode uses still works and will work, if you need dynamic properties without define it in your class add the attribute for this class #[AllowDynamicProperties] . > There was a somewhat recent article that talked about changes for a string template literals cleanup for the next major version that will break a whole bunch of code as well. Next major version comes in several years until then you get deprecate warnings, if you can't fix problems that will occur in 2-3 years you should think about your software development skills. > But what about many projects? What about transitive dependencies? If you have many projects but no manpower to maintain it thats a bigger problem for the projects itself, e.g. security.
And you can use phpunit combined with rector for many projects. > PHP is moving fast and makes no excuses. It's simply not a language that prioritizes stability. PHP is stable if you write good code and on the same level as nodejs or python. > There are so many little gotchas and weird behaviors.
Thats the reason for the upcoming breaking things, if php would stick at php 5 it would be dead. |
AKA churn. Breakage is not OK.
PHP breaking every couple of years and showering you with deprecation warnings doesn't fix that.
It's like saying: "In a month I will punch your face, you better make sure to wear a helmet!". Just because you said that doesn't make punching people's faces OK.
There are languages and tools that don't break within that time frame and there are languages and tools that _never_ break.
There are also better ways of breaking changes: If you do break then give me a canonical, reliable, automatic upgrade path that also rewrites vendored dependencies.
> (...) if you can't fix problems that will occur in 2-3 years you should think about your software development skills.
It's not that we can't fix them. It's that we have better things to do but _must_ fix them.
Many of those changes are not critical or security related. They are just changes for the sake of change without consideration for stability. Everyone hop into the hype and churn train!
The baseline expectation is that my fundamental tools are backwards compatible and stable. People also have dependencies, transitive dependencies and so on. Dependency management is already hard enough without breakage.
Without stability there must be some _major_ advantage that we cannot get anywhere else. Stability ensures that fundamental libraries and tools can be _done_ outside of voluntary optimization and extension. It means you don't have fix code in multiple places and multiple projects without a compelling reason.
That's what I was getting at.
---
Note: There are good things about PHP and parts of it's ecosystem that I'm not talking about in this comment. This is a rant based on unnecessarily inflicted pain.