> If you don't check what you pass to count() it's really not php's problem, it's your programming.
this is a horrible take, language semantics should never change in a backwards-incompatible way. This is API design 101.
this is a horrible take, language semantics should never change in a backwards-incompatible way. This is API design 101.
I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better?
No other reasonable language does this.
What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened.
On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.
this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?
I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal.
It just boggles the mind.
Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc).
> Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code
That. Is. The. Entire. Point. Of. Major. Versions.
A big red warning and culutral understanding of "stuff we said would be gone, that we gave you a year+ of notice on, is now gone, go read the migration notes if you've been sleeping under a rock."
You act like this is happening monthly? 8.0 came out in Nov 2020... , 7.0 was Dec 2015.
> I just don't understand why people accept this from their tools.
Actually our tooling is pretty nice. Between psalm, phpcs and rector, we have tooling that can forwarn of deprecations in use, and most of the time fix them automatically.
Should you always use PHP? No. But the debate on the nuances as to when to not use it doesn't tend to go well with those who just throw everything out the pram acting like PHP developers are insane because it's not a haskell/rust docker project.
Excuse me, where do you work? Do you not have a company policy about not using software that isn't actively receiving security updates?
> Hell, there's still a lot of 5.x deployments out there that work just fine.
forgive my ignorance but I was under the impression 5.x isn't actively maintained anymore?
The enterprise client is the one on 5.x (for an interop program for B2B order processing), in a secured intranet system behind firewalls (multiple, on occasion one of their teams breaks one while updating it and we lose access for a day) and a VPN.
They might get up to 7.x this year when they retire the server "our" VM within there is on and reprovision to some new metal.
But by all means, go try and bypass their procurement and change process. I'm sure they'll appreciate your insight into rapidly changing a component of one of their main revenue streams... Just let me grab some popcorn first :)
To be a little less cutting, its admirable to want to be clean and proper, to do it all the right way 100% of the time... But that ain't how the world works and you either bend to accommodate and try to do some good, or scream into the digital void... Your choice.
Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.
For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today.
As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
Nobody is saying that. The golden rule of API design is do not break your customers.
The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
> [...] randomly change their APIs every couple of months [...]
This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months.
I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.
PHP should learn from that, instead of trying to repeat it (in slow motion)