Comment by dgb23 | Hacker News Reader

Comment by dgb23 | Hacker News Reader

Parent Full thread

> This RFC proposes to deprecate options 3 and 4 in PHP 8.2 and remove them in PHP 9.0.

Why remove it? Why break everyone when you can just deprecate it indefinitely or at least for a very long time?

Deprecated it, write clear warning messages with links to official docs, suggesting alternatives. Update official docs to reflect the idioms. Done.

PHP as a language and ecosystem seems to be evolving backwards from a reliable, productive and accessible tool to something that is breaking callers, introduces versioning and upgrade issues.

And it's already harder to debug than competing languages, because errors are spread across the server, the language runtime and even within that there's different types of error systems with error reporting, exceptions, error values and so on.

I'm impressed by some of the improvements that PHP went through and there are some rock solid tools and libraries (the star here is composer) but at the same time I feel less and less confident using it from a stability perspective.

PHP seems to be doing better and better with tooling since the plethora of changes got gradually added.

Due to the introduction of better types support; psalm, phpstan, can statically analyze your PHP code and surface bugs that you might overlook in the past. Of course this is what static typing programmers have been preaching all along, but you don't have to go all in, some gradual typing is enough to get benefits.

Ok, you don't want to use the extra type support that PHP nowadays has, you can still benefit from it. Tools like https://github.com/RectorPHP/Rector help you automate PHP code updates, and changes between framework versions. Even the linked proposal includes a script based around the recent-ish PHP built-in tokenizer (no regex shenanigans), to migrate the code for you.

There's some churn, but generally deprecations are sensible. I'm also active in other language communities and deprecation paces are comparable IMO.

> errors are spread across the server, the language runtime and even within that there's different types of error systems with error reporting, exceptions, error values and so on.

To the best of my knowledge, errors are not spread across anywhere; server errors have nothing to do with PHP, and would happen regardless of the backend language you're using.

As for different types of errors, the PHP team has been hard at work moving -everything- over to exceptions. It's precisely because they're willing to remove old/obscure/confusing parts of the language and clean the syntax up, that it has been able to evolve into the fast & modern language it is today.

> PHP as a language and ecosystem seems to be evolving backwards from a reliable, productive and accessible tool to something that is breaking callers, introduces versioning and upgrade issues.

Having 7 different methods to do string interpolation is not "productive and accessible", it's confusing and prone to abuse.

The whole "never break user land/space" axiom that the PHP core used to follow isn't healthy for the language, and I'm glad we're moving away from it.

I want PHP to grow into a more modern and stricter language, and I can understand that iterating fast and deprecating old behavior is part of that evolution.

> The whole "never break user land/space" axiom that the PHP core used to follow isn't healthy for the language

I would say it's not healthy for most languages.

Perhaps it can also be renamed "SHP" (strict homepage processor)

Why would anyone prefer a tool dead set on undoing their productive investments with each new release? Decisions like this are a massive red flag. It doesn't allow the feature to be removed (interpolation still exists and isn't going away), I doubt it simplifies the code much, it just breaks existing projects out of essentially a stylistic preference. That's not a tool I'd ever want to depend on

Did you read the full RFC? It's not strictly 'stylistic preference' as each version has slightly different capabilities and there's potential ambiguity between some of those capabilities.

Reply on news.ycombinator.com