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.
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
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.
I worked on a Wordpress site a few years go, having to add a fair amount of plugins to spin up an MVP of a product we were testing. The incredibly goofy code I saw in those plugins was shocking. Things that should never have made it to production were in there; commented out blocks of code, TODO lines, random log output, complete nonsense comments.
Granted, I shouldn't throw the first stone - at least they didn't commit any obvious profanities, like I did when I was young. But it was just ... very clearly output very quickly.
Go write a better plugin if you've got a problem with it.
The users don't give a shit about any of those things.
The hate on WordPress and PHP by developers here astounds me. WordPress actually gives a shit about backwards compatibility. Unlike literally every modern JS or PHP framework I've used over the last decade has been an utter cluster fuck to keep in production.
Those WordPress websites I set up 10 years ago? Turn on auto updates and forget about it. Maybe 1-2 times I've had to resolve something on them.
Those react, Angular, Vue, laravel, express sites? They lasted a year before npm stopped being able to build updates hell they couldnt even build from a "lock file" (my fuckin ass it is).
What a waste of fucking time. All cause some dipshit kid thinks his "better" way of doing something is worth my time to update my websites.
This seems like a bit of an angry response. I write a lot of Wordpress and php code and help manage one of the most sold themes on theme forest. Php really was, in my opinion, a hell hole of a failed language until 6ish. The patterns people used as standard practice were 5-10 years out of date either due to the slow progress of WP or the php language and ecosystem. A lot of the flack PHP and Wordpress has gotten is totally deserved. Yeah it can just work, but at what cost? Maintenance and upgrading is terrible. Security vulnerabilities galore. You seem involved in WP but just work is a load of bullshit. Everytime we push an update people migrating are walking through a minefield: CSS overlaps, JS import overlaps, php bugs from other plugins. Going back, we can’t even use features from modern PHP because most of our users php versions aren’t well up to date.
Wordpress itself has done a terrible job halfbaking different systems as part of WP core. Gutenberg, imo, is just another abject failure that will take 5 years and provide a buggy solution. You are spot on with the compatibility argument which also has lots of pros and cons obviously.
Also for most js websites built at a certain time things weren’t using npm and bundles and you can simply link the js src like it’s 1999. Just save the source code and you never have to update.
I know this is a trope here but every job has the right tool. WP and php are great tools, especially PHP right now, it has literally never been better. WP on the other hand is just totally confused with Gutenberg and it’s clear Automatic has no idea what they’re doing and who their audience is.
As a full-time WordPress developer, I often do "go write a better plugin" when I have a problem with it. But that doesn't mean it's incorrect to say
> The incredibly goofy code I saw in those plugins was shocking. Things that should never have made it to production were in there
And the owners do
> give a shit about [many] of those things.
because the checkout will start to fail silently. One time for us, customers couldn't check out unless they entered an apartment number.
The standard of code in the WordPress ecosystem is sub-par.
Unit testing, static analysis and linting are NOT the norm.
Part of my routine is to read the error logs, fix the rookie mistakes introduced in plugin updates, and send the fixes back upstream. And when I say send, I mean email them or open a support thread on WordPress.org. It's a blessed day when the plugin is on GitHub for me to make a PR.
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.