zlacker

[return to "PHP 8.2"]
1. Cianti+R7[view] [source] 2022-12-08 13:21:04
>>TimWol+(OP)
As someone who has written in past a lot of PHP and Python, I find it interesting that PHP devs can do a lot of breaking changes, and don't get a huge amount of flak for it.

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.

◧◩
2. mgkims+S8[view] [source] 2022-12-08 13:29:01
>>Cianti+R7
Can you give some specific examples? I can't think of too many 'fundamental breaking changes' in PHP between major versions. Some things that will be changed in 9 are now deprecated in 8.2.

PHP has gone through a few changes.

PHP 3->4 was a moderately big change under the hood, and introduced a lot of new things, but most 3 'worked' under 4 (but was... awkward).

PHP 4->5 - a few 'big' things changed - XML processing changed - I had to use some shims to get some projects upgraded.

PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects. I can't recall too many major breaking changes, but it was mostly just getting a doubling of speed without any substantive changes.

The PHP community has a couple decades of 'major version changes' to look at to learn from. I still can't say I agree with 100% of the decisions, but it's still progressing nicely.

◧◩◪
3. denton+Vj[view] [source] 2022-12-08 14:42:34
>>mgkims+S8
> PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects.

They replaced the MySQL plugin in version 7. All MySQL code was broken. I don't know, but I'd guess that most PHP sites were using MySQL as their database (the 'M' in 'LAMP' stands for MySQL).

◧◩◪◨
4. danari+0s[view] [source] 2022-12-08 15:27:21
>>denton+Vj
I thought I had to replace all my mysql code in a massive overhaul to upgrade from 5.x to 7.x.

Then I read a little closer, and realized I pretty much just had to add an "i" onto all the underlying mysql functions ("mysql_" to "mysqli_"), at least for the ones I was using commonly.

I'm still in the process of migrating that project, now on 7.4, to a modern Symfony framework, but I tested it out in 8.1 the other day, and it needed...1 change to work apparently perfectly.

I'm still going to need to do more thorough testing before I put production on 8.x, but with 7.x now unsupported, that has become a priority.

◧◩◪◨⬒
5. mgkims+JP[view] [source] 2022-12-08 17:07:26
>>danari+0s
IIRC the parameter order for some parameters differs between mysql_* and mysqli_* functions. But as someone else said above, built-in PDO or some other abstraction library for data access has been the way to go for more than a decade (more like closer to 20 years at least).

That said, I'm still surprised when I come in to codebases where people are still using hard-coded db function calls all over the place (mysql_* or mysqli_) I indicate that abstracting that away should be a priority. Even doing something as simple as "I want to log all the queries that I'm making for debug purposes" is essentially impossible when you have hundreds of individual calls to mysql_ embedded throughout the code. But... I've not come in to a codebase in the last... 4-5 years that does that, so either I've been lucky or that coding behavior is indeed becoming a thing of the past.

[go to top]