▲ 81 points
back
90 comments
Having used PHP a long time ago, this is very confusing to me. I would have thought that "${var}" does exactly the same as "$var", but being usable in more cases. For example if you want to append text without a space: "${var}moretext". This is how it works in Bash, at least.
I am really surprized that braces on the outside works at all. I would have expected "{$var}" to expand to "{FOO}".
I thought the version with parentheses is some new general-expression syntax, like "${( $foo + 2 )}" - but that doesn't seem to exist. I would have expected "${(var)}" to give a warning, like the classic "`var` is not a constant. You should use `$var`. Accessing `var` without `$` will stop working in a future version of PHP". (As I said, I used PHP a long time ago...).
PHP is indeed still "a fractal of bad design" :-D, because it gives you the illusion of being able to come back and pick it up easily. But everything does something slightly different than you expect. I commend the PHP devs for removing the footguns and making it a nicer language again!
Personally, I would have removed #2 and #4 - keeping only "$foo" and "${foo}" as equivalent, just like in Bash. And when they get a general expression syntax - maybe "$(foo)" like in Bash, or something else - then you get variable variables back for free.
As someone who uses PHP nearly every working day, this RFC is the first time I've ever seen the ${var} syntax in PHP. It only gets a very brief mention and a single use in an example snippet in the documentation[1]. I don't think I've ever seen it in production code, and would have flagged it as a typo if I found it during code review.
Removing {$var}, on the other hand, would have broken practically every string interpolation I've ever written, and probably about 50% of all uses of string interpolation in the ecosystem.
[1]: https://www.php.net/manual/en/language.types.string.php#lang...
The ${var} syntax has always been my preferred approach. In all the editors I’ve used it syntax highlights as if you had typed “.$var.”, rather than just displaying $var in bold and same colour as the string literal. Plus it allows for more flexible use of arrays or objects
Sad to see the way PHP is killing backwards compatibility. There has always been a way to bodge it with previous BC breaks like removal of mysql and mcrypt, but this isn’t fixable without code changes. I don’t even see any advantage, seems like change for the sake of change
Again? Has it ever been a nice language?
For throwing a little web page together with a small amount of dynamicism, or for including headers and footers, PHP was great. For learning, it had just the right amount of power vs. ease of use.
Of course, PHP has all the well known crazyness and technical debt that drove many away. I now prefer Python, although the same thing is often a lot more verbose in Python than in classic PHP, I know I can maintain it better. "Modern" PHP with classes, stricter typing and templating engines is close, but it loses the easyness of drop-in `<?php ?>` .
Incidentally, I worked on a Wordpress site recently. It was a blast from the past and not in a good way. The coding conventions have not changed in decades, and it is `<?php ?>` and global variables all the way.
These two lines of code are now deprecated, and will be removed in PHP 9.0. My question is: what will they do in PHP 9.0? Will they throw a syntax error? Or will they print something else?
echo("${foo}"); // Will this print '${foo}' in PHP 9.0, or will it raise a syntax error?
echo("${(foo)}"); // Will this print '${(foo)}' in PHP 9.0, or will it raise a syntax error?
Even worse, it will reveal the variables used by your page to the user, which in some cases can be a security risk.
I assume it will raise a syntax error, as the PHP team is good about these things.
But that's also stupid because you cannot actually simplify the parser that much then, as you still need to detect it. And then you could just keep supporting it anyways, since it pretty much calls into the same code as the surrounding curly braces after that.
A syntax error would be \s fun though, would you have to escape the sequence in order to get that intentionally?
If you have display_errors on, you have much security risk than this.
If you set error reporting to E_ALL I assume you will get a 'undefined variable {foo}'.
Which I think will be loud enough.
Personally, I would prefer if they just left working code alone.
Don't panic: this deprecates `${var}`, which is a less-common syntax for interpolation, but leaves the most common ones, `$var` and `{$var}`, in place.
It reduces the number of slightly different ways to do one thing, and clears the ground for adding any-expression interpolation, which PHP is currently missing.
I'm not worried about the deprecation itself. I'm worried about the second argument you're making. This RFC trades stability for nicer syntax that isn't really needed. PHP is already great with strings. If the deprecation was indefinite and there wasn't a language feature waiting that relies on removing this, then I would not be worried at all. Will the implications be bad in this case? Probably not? It's the mentality behind that makes me uneasy.
PHP has been modernising for years. This particular change feels like a bad move to me (pointless) but it's part in parcel with them modernising overall and I don't want to discourage that as most of the improvements have been extremely beneficial. Speed upgrade from 5 to 7 was insane.
I've never known that "{$var}" was even allowed. All other languages using $ for string interpolation use the "${var}" pattern, often also allowing any expression ("${var / 10 + 2}") within the brackets.
Keeping "{$var}" seems like a strange decision to me. I assume the people who made the decision analysed open source projects and evaluated which option gets used most, but it doesn't feel like the most obvious decision to me.
You'd have to rewrite a good portion of all existing PHP code to eliminate the "{$var}" syntax. It is the "right" way to include variables in a string.
"{$arr[2]}" for array and object, {} is required.
But why remove it in the first place. Is it such a burden on the parser or mental overhead for developers?
Because this syntax is used for variable variables as well as interpolation.
By removing the interpolation, it makes the remaining code more predictable and less likely to have a footgun.
> clears the ground for adding any-expression interpolation, which PHP is currently missing
I don't like such changes. Php 8 had a lot of breaking changes and upgrading it is already an arduous task. If I don't upgrade then package will demand php 8. If I don't upgrade package & language then I must stay alert of security vulnerabilities. And, changes like this makes relearning difficult. I wonder why majority of people in rfc voted "yes"
Thankfully I am investing in Rust language which has stability guarantee. In my opinion language shouldn't move fast. There should be balance. All those tutorials, guides become useless. There is a reason why COBOL is still used for 90%+ atm swipes.
There should be the php equivalent of LTS (long term support). After such a long time on php 5.. it felt like one of the features of the language was stability. Your old code ran. 7 was much faster so easy sell to upgrade. the versions obsolescence treadmill has begun.. I like the language but having to upgrade this frequently (every couple years) is a bit much.
We should just stop messing with it. PHP is what it is, if you want something better/different build another HACK.
At this point the language works and works well. Everyone knows where the sharp edges are. The only people who are unhappy are the people who are forced into being PHP devs by $dayjob and would prefer a different language.
> Php 8 had a lot of breaking changes and upgrading it is already an arduous task.
How so? I've upgraded most of my project to PHP 8 quite easily. Which versions were you running before, and what breaking changes did you see?
Not OP, but the only one that I know of and that can trip you up without giving any form of warning is the change of resources types to class types for some of the libraries, like curl.
Thus if your old code did a check like is_resource it will now return false instead of true.
> Thankfully I am investing in Rust language which has stability guarantee
For 25 years? Because that’s the timeline we’re talking about for PHP. There’s cruft after 25 years that should be cleaned out. Java is doing the same (but slower, and there’s less cruft).
You seriously think Rust or any language doesn’t need to change backwards compatibility for 25 years?
If you are using PhpStorm you can run a code analysis for a PHP version.
I did this on a large project made for PHP 7.2, including the vendor folder. The changes I had to make were minimal and were done within half an hour.
If this makes the language better, why not?
Can you tell me what in PHP 8 you're struggling with? Pretty much everything listed here has been deprecated for a long time or used by almost nobody: https://www.php.net/manual/en/migration80.incompatible.php
I've made my whole career about PHP and had no idea it supported stuff like (uncast).
In almost two decades of PHP programming, I can remember that I was 'forced' by a webhost to update my code only once. They went from PHP5 to PHP7 - if I recall correctly - and I had to change some MySQL function calls to MySQL PDO.
It was slightly more work than changing function calls, but if my code had been object oriented at that time, it would have cost me one hour max. Your mileage may vary for bigger code bases.
Edit: okay, make that two hours.
I see many aren't familiar with https://github.com/RectorPHP/Rector . It will help you with a bunch of PHP&frameworks migration work.
> 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
Big fan and longtime user of PHP here. Personal code has been providing business value with hardly any changes for 10 years. What has burned me recently is BoltCMS 3 using lots of symfony packages that don't work on PHP 8 anymore. There's a new version of the CMS, but it's a rewrite meaning lots of work to rewrite extensions and customization. Really grateful for the good open source CMS and PHP, but it's hard to sell customers an expensive update that won't give them any visible benefits. Those customers might decide to spend the money to build a new website with somebody else instead. PHP5 and 7 were quite backwards compatible, but sadly PHP8 seems to break a lot. New versions are supported for a much shorter time now.
So while I still like PHP and the good work they are doing, the maintenance cost has sadly steeply risen recently. SLAs are a necessity now.
With dynamic language like PHP where there is no traditional compilation step by the programmer, these new deprecations will lead to lot of subtle bugs to be found in production.
This was to certain extent the same problem with Python 2.0 -> Python 3.0 changes. I remember not liking the process with that, however I understand the need to deprecate some features for performance etc.
PHP should have built-in tool to scan source code for likely deprecations, there are third party tools but I haven't tried those. Given that there is a lot of code with PHP whom nobody anymore really bother to maintain, but it still has to work, it would be beneficial.
Thanks for sharing this. It's good to remember that even relatively pragmatic languages like PHP often deprecate syntax features simply because they're "inferior" to another syntax feature.
Well, PHP approach to features is not really "pragmatic", it has boiled down for decades to basically adding whatever they could rip from somewhere else, without the slightest trace of logic behind it. When they deprecated and removed mysql_* way way more impactful IMHO, it basically broke half of the websites on the web. Was it worth it? Absolutely yes, because mysql_* functions were utter garbage and have caused unmeasurable damage over the years with their shoddy approach to sanitizing. Sometimes you have to atone for your sins, and that's what PHP has been doing in the last few releases.
> When they deprecated and removed mysql_* way way more impactful IMHO.
Also folks just moved onto mysqli_* and reused the exact same footgun.
They've been doing that since 5.2
PHP has a strange identity problem. For a language that most would agree is used due to past popularity, it has a lot of breaking changes. But while syntax gets deprecated and function signatures changed, the stdlib is still a mess. The original randomly long functions are still there with no replacement in sight. To make my point, there's still no reasonable int parsing function!
I'm not against change, but PHP devs should decide if they want to make code maintenance easier, or make PHP an actually good language. Right now, it's in a weird in-between state. I'm not a fan of coming across old PHP code and having to make a bunch of small changes to port it to supported PHP.
Well, they basically took the __looks__ of Perl and bolted on a dynamically typed Java on top of it. I don't think there are languages more different in concepts and values than Perl and Java, and PHP is the result of that unholy mixture. Perl is crazy, but it has a very precise logic behind the madness. Java is boring and predictable. PHP is crazy while being completely random.
They've gotten more aggressive lately in wiping away the dusty corners of the language, little-used alternative syntaxes like these,some of the footguns. But nothing even approaching a full reorg/rename of the stdlib.
I think the sense is doing something like that would get you into an undesirable "Python 3" type scenario. Instead, the sort of unceasing wave of deprecations leads to some make-work but doesn't seem to cause the same kind of long term resistance to updating.
> there’s still no reasonable int parsing function!
Well, I suppose it depends on how one defines “reasonable”, and perhaps how one defines “parsing” (e.g., what is it you’re trying to do). As a comment elsewhere observed, while
(int)$val;
filter($val, FILTER_VALIDATE_INT);
Is this the best way to do it? Probably not. But I think I’m okay with testing that filter in an if statement rather than wrapping the type casting in a try/catch block.
However:
> I'm not against change, but PHP devs should decide if they want to make code maintenance easier, or make PHP an actually good language. Right now, it's in a weird in-between state. I'm not a fan of coming across old PHP code and having to make a bunch of small changes to port it to supported PHP.
If the dichotomy you pose in the first part is correct, then “coming across old PHP code and having to make small changes” is unavoidable if they’re striving for the latter. Given that they’re clearly not down for making radical changes that break everything everywhere all at once, then it’s going to be in a “weird in-between state” for years, isn’t it?
stdlib will never change, because it would break every PHP project out there. Many of the previous deprecations as been relatively easy to handle, like switch from each to foreach, or make sure that you don't pass null to stdlib functions, but changing the stdlib itself would instead be a complete nightmare.
Remember that many projects out there needs to support multiple PHP versions at the same time, it would be extremely confusing if the stdlib started to do subtle changes between versions and also hard to properly handle and detect.
Like if you would swap $needle and $haystack for strpos(), it would be nightmarish to statically detect in an existing code base which is the correct order and quite hard for a human.
Introducing aliases is also a bad idea, there already exists aliases in the stdlib and they only add confusion when reading code, that would be true for new aliases as well.
Named arguments alleviates the problem with argument order in exchange for more verbosity.
What PHP could do is to introduce primitive objects, e.g. $str->substr(...), however that would not guarantee a well designed standard library either, because RFC:s and emails is not a good forum for designing API:s.
I think the correct solution is to implement operator overloading and let the community design a standard library/libraries. Because of the massive performance improvements of PHP the standard library is no longer required to be pure C, it can either be implemented in PHP or wrap the existing stdlib.
Deprecat PHP.