[skloubkov]

While I understand why this was done (for the sake of comparability), I feel like its better to bite a bullet and slowly phase out broken functions over several versions.

Warn initially (few versions) and then raise exception/critical errors after. If developer isn't willing to update, chances are server isnt being updated either anyways.

[damncabbage]

Well, not really. Consider the (very common) case of a PHP-based blog, forums or shop being hosted on shared hosting. The latter gets an upgrades, and the site explodes.

(I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)

[shoyer]

Better idea: bite the bullet, drop PHP. Switch to a language that was designed. In the eyes of many of us, PHP is beyond redemption.

[skloubkov]

Difficult to get as sign-off on re-write of large systems when there technically nothing broken.

[Killswitch]

Better idea: Be a better programmer and don't blame a language because you suck.

[prodigal_erik]

No amount of "being a better programmer" can fix the fact that $x == $y && $y == $z does not guarantee that $x == $z or $a[$x] == $a[$y]. Nor that passing by value may or may not protect you from destructive updates, depending on whether your caller passed by reference. The language simply can't be trusted to behave predictably; a huge number of its features have some kind of trap built in by mistake.

[jl6]

Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.

[prodigal_erik]

Builtin features you can't override have data-dependent bugs. Most values work, but some values fail (deterministically) and most users don't know that. You can't even fix the interpreter unless you're running a non-shared copy and are not running any third-party code which happens to rely on the odd misbehavior.

Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.

Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.

[awestroke]

So, PHP is a good tool because a 'better' programmer can make good things DESPITE using PHP?

[jl6]

Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism.

If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.

[jtreminio]

Nothing in this discussion mentions anything broken, though.

[Yver]

Indeed, and the title is incorrect too. Function names were not renamed to end up different buckets; Their names were picked that way.

[Someone]

What about usability? "I wasn't too worried about not being able to remember the few function names." certainly indicates that usability decreased. That may have set a pattern for it getting broken, eventually.

[skloubkov]

This. I was implying that length of the string should mean length in characters, not bytes. This could lead to broken code and would require programmers to keep in mind both.

I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.