4 ms·

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 case

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.

xigoi 4y ago
Again? Has it ever been a nice language?
- captainmuon 4y ago
  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.
  - pavel_lishin 4y ago
    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.
    - dhzhzjsbevs 4y ago
      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.
      - BrianHenryIE 4y ago
        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.
jorams 4y ago
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#language.types.string.parsing https://www.php.net/manual/en/language.types.string.php#lang...
- kiririn 4y ago
  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

xigoi 4y ago

Again? Has it ever been a nice language?

captainmuon 4y ago
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.
- pavel_lishin 4y ago
  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.
  - dhzhzjsbevs 4y ago
    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.
    - BrianHenryIE 4y ago
      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.

jorams 4y ago

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#language.types.string.parsing https://www.php.net/manual/en/language.types.string.php#lang...

kiririn 4y ago
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