PHP RFC: Deprecate ${} string interpolation
wiki.php.net
wiki.php.net
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.
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.
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.
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.
> 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.
The forms API in WordPress, for example, require you to output HTml directly from the callback function.
Granted, it was a design that make sense 15 years ago, but I would have though there would be newer API.
It work fine, sure, but doesn't mean I have to like it.
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.
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...
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
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?
I assume it will raise a syntax error, as the PHP team is good about these things.
Which I think will be loud enough.
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.
By removing the interpolation, it makes the remaining code more predictable and less likely to have a footgun.
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.
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.
I've made my whole career about PHP and had no idea it supported stuff like (uncast).
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?
Thus if your old code did a check like is_resource it will now return false instead of true.
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?
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.
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.
If you don't like it you are free to continue using an old version.
Expecting a language to stagnate because you don't like learning new things is asinine and doesn't hold water anywhere in the programming world except among the laziest of code monkeys.
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?
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.
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.
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.
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.
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
I would say it's not healthy for most languages.
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.
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.
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.
What's wrong with (int)$val ?
Why this arbitrary restriction? A forced cast of a string to integer is always guaranteed to produce an integer.
And, if you naïvely use the suggested function for the purpose you've suggested it for, e.g., like,
if(!is_numeric($input)) { error(); }
else { return (int)$input; }
/**
* Cast to int, fail if not a valid integer
* @throws \UnexpectedValueException
* @param mixed $thing
* @return int
*/
function as_int($thing): int
{
if (!filter_var($thing, \FILTER_VALIDATE_INT))
throw new \UnexpectedValueException("Value is not an integer.");
return (int)$thing;
}
Your function proves my point: It looks correct, but actually breaks for as_int("0"), since filter_var with FILTER_VALIDATE_INT doesn't acutally validate the int, but parse it, and zero is falsy.
/**
* Cast to int, fail if not a valid integer
* @throws \UnexpectedValueException
* @param mixed $thing
* @return int
*/
function as_int($thing): int
{
$int = filter_var($thing, \FILTER_VALIDATE_INT);
if ($int === false) {
throw new \UnexpectedValueException("Value is not an integer.");
}
return $int;
}
And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up.
I see this from the other side: Good languages guide programmers toward good solutions. Criticism of the simplest or obvious solution is valid, because the language determines what that solution is.
Conversely, arguing that it's possible to write good code is largely meaningless. It doesn't mean that the language is good, just that it isn't completely unfit for purpose. Just look at the number of people who commented about other int parsing methods: Are they bad programmers, because they didn't know to look for filter_var when parsing ints, or is PHP a bad language because something so simple is hard to find a solution for?
1) Some programmers are just either too lazy or too arrogant to read the manual, thus bad programmers. As a senior programmer that has helped numerous juniors in their work, this is probably one of the most common mistakes I see, they write code without checking how the API works, or they ask me why something isn't working when it can be easily found in the manual. This is not specific to PHP and I have seen this in everything from PHP to C++.
2) PHP is dynamic language, similar to JavaScript, types were not something you historically bothered with, thus parsing to int is not something the community has a large shared knowledge about, similar how it is rare in JavaScript. However with the introduction of primitive type hinting it has become more common to do proper parsing, hopefully PHP programmers will learn eventually. Thus it is a thing with dynamic languages, not specific to PHP.
3) Why can't programmers find the filter_var method in the manual and/or in the standard library? This I considered as valid criticism of PHP, the standard library is not structured because of the C like flat structure and many of the stdlib functions are weirdly named, like filter_var, what is filter to begin with?
The solution is to build a better stdlib, not throw out the language. I think the community can build a well designed stdlib if PHP implements operator overloading. The performance issues is no longer valid, PHP 7+ has great performance, thus worrying about losing important cycles is not really true anymore.
PHP as a language works well to build good solutions, I have done so in many projects. The critique here evolves around the stdlib, that is not something new.
PHP needs to actually have a good standard library in its default distribution. Maybe looking to large frameworks like Symfony to develop one isn't a bad idea, but they've largely left the stdlib alone, so just waiting for them to start developing a complete replacement isn't going to work.
(For all its faults, JS' parseInt function is perfectly serviceable, but that's beside the point.)
It has been proposed before to have PHP source shipped with PHP (and also the possibility mix C and PHP) and think that would be the best option.
One option could be to have slower evolved stdlib in core and a faster community version with composer.
Reason why I’m proposing to develop it outside of core is because a rfc based process is not necessarily the best approach to design a good & well functioning api (and empirically that is true).
It is better to deliver a complete stdlib (or major sub parts) as one or multiple rfc.
And by doing like this you allocate resources better, the few with knowledge about PHP internals can keep focusing on that while the community, a much larger group, can design a stdlib.
And PHP has done a lot of great work on making user land and stdlib on equal footing, so now you can implement strpos(…) to exactly match the stdlib version thanks to union types, similar argument parsing and using same type rules (type errors) between the too.
Only major thing I know of that differs when exposing an api, that is either from a PHP C extension or PHP code, is operator overloading.
A rfc proposal to add it was unfortunate declined, but I’m hopeful that on day it will be added in some form because of this reason, it ought to be possible to express the same intent regardless if it is from C or PHP.
With user land operator overloading we can implement object based primitives with methods instead of the current function based approach. And it could be possible to extend it.
Other nice things you could do is to implement safe and unsafe string handling to avoid injections.
With operator overloading the community can evolve the language without the need to evolve PHP itself.
Right now I guess that the alternative is using is_numeric and then casting to int if possible.
Edit:
> (int)$val === false
Would always be false because comparing two types, an integer and boolean would always be false.
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.
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?
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.
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.
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.
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?
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.
Also folks just moved onto mysqli_* and reused the exact same footgun.