8 ms·

PHP RFC: Deprecate ${} string interpolation

81 points by gslin 5y ago

phendrenad2 5y ago
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.
- dvdkon 5y ago
  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.
  - baisq 5y ago
    >there's still no reasonable int parsing function What's wrong with (int)$val ?
    - dvdkon 5y ago
      There's no error handling, (int)"x" === 0.
      - RedShift1 5y ago
        You should use the filter functions for that
      - Y-bar 5y ago
        Why should that be an error? First we are explicitly forcing a string to an integer and then comparing it with type sensitivity to another integer.
        dvdkon 5y ago
        We could debate that for a long time, but my point was different: There's no sane function in today's PHP that parses ints and handles errors (defaulting to 0 doesn't count).
        Y-bar 5y ago
        > defaulting to 0 doesn't count Why this arbitrary restriction? A forced cast of a string to integer is always guaranteed to produce an integer.
        dvdkon 5y ago
        And a forced cast is therefore a bad way to generally parse a user-provided string to int.
        Y-bar 5y ago
        So why do you insist on using it that way?
        dvdkon 5y ago
        I don't. I asked for an int parsing function, got (int)$val as a suggestion, so I had to explain why it doesn't fit the bill.
        samus 5y ago
        And how are we supposed to distinguish that from a legit 0?
        Y-bar 5y ago
      - zerocrates 5y ago
        You can kind of get this to happen in 8 and up: Doing math on a non numeric string is then a catchable TypeError so you can do 'x' + 0 in a try. Doesn't avoid other PHP numeric-string stuff like scientific notation and floats being accepted, though. Passing to a int-typehinted function param in 8.1 gets you closer (will complain about float strings) but is currently just a annoying-to-work-with deprecation notice. Presumably it will eventually also be a TypeError.
      - deleted 5y ago
        [deleted]
  - dsego 5y ago
    Lib functions are vertically consistent with the underlying libraries. https://youtu.be/nmD1Q4FsXCc?t=845 https://youtu.be/nmD1Q4FsXCc?t=845
    - dvdkon 5y ago
      Yeah, PHP sometimes pretends it's a C derivative. I think it's a stupid idea most of the time, especially with regard to strings. C string handling isn't anything scripting languages should copy. Besides, PHP now has its own (partly duplicate) class-based stdlib for some things, why not be consistent and "replace" all of the old stdlib?
      - dsego 5y ago
        > C string handling isn't anything scripting languages should copy. Or C-like imports, it's ridiculous tbh, inlcude, inlcude_once, require, require_once. My understanding is that PHP started as a basic templating language, a way to embed c function calls as tags in HTML. In that way it's ingenious, people keep reinventing it with JSX, filesystem routing etc. Right now I'm thinking PHP should've gone the other way. Instead of adopting features to resemble other general purpose languages (things like classes from java and so on) it should've doubled down on web stuff, like JSX - in the sense of having a nice syntax for partials/components, eg <php-component props /> instead of <?php echo php_component(props) ?> and other comfort features, to become a platform.
  - qalmakka 5y ago
    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.
    - TedDoesntTalk 5y ago
      This is a good summary of PHP in the past and maybe the present. I think the PHP 10 years from now won’t have the craziness anymore, based on the current trend.
  - zerocrates 5y ago
    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.
    - jwommack 5y ago
      They pretty much already had the "Python 3" issue with PHP 6, the unicode PHP
      - zerocrates 5y ago
        Yeah, but it never came out. A bullet dodged.
    - mschuster91 5y ago
      > But nothing even approaching a full reorg/rename of the stdlib. It's been a long tradition in the PHP world to keep the PHP side of a module somewhat consistent with the underlying C API that the module exposes. On the one side, people with a C background immediately find themselves at home in PHP - on the other side, "new" programmers coming from the Java, Go or the matured JS world are confused because of all the inconsistencies.
  - chipotle_coyote 5y ago
    > 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; will force a non-integer $val to be 0, if what you’re trying to do is determine whether $val is a string literal that represents an integer, you can use filter($val, FILTER_VALIDATE_INT); instead. That will return the integer if it is, and false (actual boolean false) if it isn’t. 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?
  - tored 5y ago
    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.
- qalmakka 5y ago
  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.
  - jwommack 5y ago
    They've been doing that since 5.2
  - teh_klev 5y ago
    > When they deprecated and removed mysql_* way way more impactful IMHO. Also folks just moved onto mysqli_* and reused the exact same footgun.
cute_boi 5y ago
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.
- ancarda 5y ago
  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 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).
- mhitza 5y ago
  I see many aren't familiar with https://github.com/RectorPHP/Rector https://github.com/RectorPHP/Rector . It will help you with a bunch of PHP&frameworks migration work.
- dreadnip 5y ago
  > 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?
  - tored 5y ago
    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.
- blenderdt 5y ago
dgb23 5y ago
> 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.
- moreira 5y ago
  > 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.
- mhitza 5y ago
  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 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.
dreadnaut 5y ago
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.
- dgb23 5y ago
  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.
  - dhzhzjsbevs 5y ago
    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.
- teruakohatu 5y ago
  But why remove it in the first place. Is it such a burden on the parser or mental overhead for developers?
  - the_mitsuhiko 5y ago
    > clears the ground for adding any-expression interpolation, which PHP is currently missing
  - sam_goody 5y ago
    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.
Flimm 5y ago
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? Personally, I would prefer it to raise a syntax error. Otherwise, code that runs one way in PHP < 9.0 will run a different way in PHP 9.0, failing silently. I would prefer it to fail loudly.
- sam_goody 5y ago
  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.
  - tuxone 5y ago
    A syntax error would be \s fun though, would you have to escape the sequence in order to get that intentionally?
  - iforgotpassword 5y ago
    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.
    - mtrpcic 5y ago
      I mean, you could just set the parser to throw an exception if it ever detects anything other than a character (a-zA-Z) after an un-escaped dollar sign. Then you can just throw the same error, "Invalid string interpolation" so that no internal state of your program leaks, and you can immediately skip any subsequent memory reads for the contents of the variable.
  - innocenat 5y ago
captainmuon 5y ago
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 5y ago
  Again? Has it ever been a nice language?
  - captainmuon 5y 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.
    - 5y ago
Ciantic 5y ago
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.
cryptonector 5y ago
Deprecat PHP.
aidog 5y ago
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.

81 points by gslin 5y ago

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.

dvdkon 5y ago
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.
- baisq 5y ago
  >there's still no reasonable int parsing function What's wrong with (int)$val ?
  - dvdkon 5y ago
    There's no error handling, (int)"x" === 0.
    - RedShift1 5y ago
      You should use the filter functions for that
    - Y-bar 5y ago
      Why should that be an error? First we are explicitly forcing a string to an integer and then comparing it with type sensitivity to another integer.
      - dvdkon 5y ago
        We could debate that for a long time, but my point was different: There's no sane function in today's PHP that parses ints and handles errors (defaulting to 0 doesn't count).
        Y-bar 5y ago
        > defaulting to 0 doesn't count Why this arbitrary restriction? A forced cast of a string to integer is always guaranteed to produce an integer.
        dvdkon 5y ago
        And a forced cast is therefore a bad way to generally parse a user-provided string to int.
        Y-bar 5y ago
        So why do you insist on using it that way?
        dvdkon 5y ago
        I don't. I asked for an int parsing function, got (int)$val as a suggestion, so I had to explain why it doesn't fit the bill.
        samus 5y ago
        And how are we supposed to distinguish that from a legit 0?
        Y-bar 5y ago
    - zerocrates 5y ago
      You can kind of get this to happen in 8 and up: Doing math on a non numeric string is then a catchable TypeError so you can do 'x' + 0 in a try. Doesn't avoid other PHP numeric-string stuff like scientific notation and floats being accepted, though. Passing to a int-typehinted function param in 8.1 gets you closer (will complain about float strings) but is currently just a annoying-to-work-with deprecation notice. Presumably it will eventually also be a TypeError.
    - deleted 5y ago
      [deleted]
- dsego 5y ago
  Lib functions are vertically consistent with the underlying libraries. https://youtu.be/nmD1Q4FsXCc?t=845 https://youtu.be/nmD1Q4FsXCc?t=845
  - dvdkon 5y ago
    Yeah, PHP sometimes pretends it's a C derivative. I think it's a stupid idea most of the time, especially with regard to strings. C string handling isn't anything scripting languages should copy. Besides, PHP now has its own (partly duplicate) class-based stdlib for some things, why not be consistent and "replace" all of the old stdlib?
    - dsego 5y ago
      > C string handling isn't anything scripting languages should copy. Or C-like imports, it's ridiculous tbh, inlcude, inlcude_once, require, require_once. My understanding is that PHP started as a basic templating language, a way to embed c function calls as tags in HTML. In that way it's ingenious, people keep reinventing it with JSX, filesystem routing etc. Right now I'm thinking PHP should've gone the other way. Instead of adopting features to resemble other general purpose languages (things like classes from java and so on) it should've doubled down on web stuff, like JSX - in the sense of having a nice syntax for partials/components, eg <php-component props /> instead of <?php echo php_component(props) ?> and other comfort features, to become a platform.
- qalmakka 5y ago
  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.
  - TedDoesntTalk 5y ago
    This is a good summary of PHP in the past and maybe the present. I think the PHP 10 years from now won’t have the craziness anymore, based on the current trend.
- zerocrates 5y ago
  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.
  - jwommack 5y ago
    They pretty much already had the "Python 3" issue with PHP 6, the unicode PHP
    - zerocrates 5y ago
      Yeah, but it never came out. A bullet dodged.
  - mschuster91 5y ago
    > But nothing even approaching a full reorg/rename of the stdlib. It's been a long tradition in the PHP world to keep the PHP side of a module somewhat consistent with the underlying C API that the module exposes. On the one side, people with a C background immediately find themselves at home in PHP - on the other side, "new" programmers coming from the Java, Go or the matured JS world are confused because of all the inconsistencies.
- chipotle_coyote 5y ago
  > 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; will force a non-integer $val to be 0, if what you’re trying to do is determine whether $val is a string literal that represents an integer, you can use filter($val, FILTER_VALIDATE_INT); instead. That will return the integer if it is, and false (actual boolean false) if it isn’t. 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?
- tored 5y ago
  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.
qalmakka 5y ago
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.
- jwommack 5y ago
  They've been doing that since 5.2
- teh_klev 5y ago
  > When they deprecated and removed mysql_* way way more impactful IMHO. Also folks just moved onto mysqli_* and reused the exact same footgun.

cute_boi 5y ago

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.

ancarda 5y ago
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 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).
mhitza 5y ago
I see many aren't familiar with https://github.com/RectorPHP/Rector https://github.com/RectorPHP/Rector . It will help you with a bunch of PHP&frameworks migration work.
dreadnip 5y ago
> 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?
- tored 5y ago
  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.
blenderdt 5y ago

dgb23 5y ago

> 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.

moreira 5y ago
> 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.
mhitza 5y ago
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 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.

dreadnaut 5y ago

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.

dgb23 5y ago
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.
- dhzhzjsbevs 5y ago
  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.
teruakohatu 5y ago
But why remove it in the first place. Is it such a burden on the parser or mental overhead for developers?
- the_mitsuhiko 5y ago
  > clears the ground for adding any-expression interpolation, which PHP is currently missing
- sam_goody 5y ago
  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.

Flimm 5y ago

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? Personally, I would prefer it to raise a syntax error. Otherwise, code that runs one way in PHP < 9.0 will run a different way in PHP 9.0, failing silently. I would prefer it to fail loudly.

sam_goody 5y ago
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.
- tuxone 5y ago
  A syntax error would be \s fun though, would you have to escape the sequence in order to get that intentionally?
- iforgotpassword 5y ago
  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.
  - mtrpcic 5y ago
    I mean, you could just set the parser to throw an exception if it ever detects anything other than a character (a-zA-Z) after an un-escaped dollar sign. Then you can just throw the same error, "Invalid string interpolation" so that no internal state of your program leaks, and you can immediately skip any subsequent memory reads for the contents of the variable.
- innocenat 5y ago

captainmuon 5y ago

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 5y ago
Again? Has it ever been a nice language?
- captainmuon 5y 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.
  - 5y ago

Ciantic 5y ago

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.

cryptonector 5y ago

Deprecat PHP.

aidog 5y ago

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.