[RFC][Under discussion] Deprecate ${} string interpolation

Rowan Collins

4 years ago

On 11/03/2022 17:13, Ilija Tovilo wrote:

> https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

Hi Ilija,

Thanks for progressing with this, and making a clear case why these
syntaxes are confusing and redundant.

I presume the intent here is that the engine will generate an
E_DEPRECATED each time such a string is encountered. Do you know yet if
that will be easy to implement? I think some simple string handling is
built into the parser, so there may not be a single code path to look at.

The other question which I'm sure lots of users will have when they see
the deprecation is: How easy is it to adapt usages of the deprecated
syntax to use the non-deprecated variants? I'm guessing it's not as
simple as moving the $ sign, because as you point out the syntaxes have
different semantics; is there a general rule that users and/or tools can
use to generate correct replacements?

A final thought is that I seem to remember a previous thread (from
Nikita?) about the "$foo[bar]" syntax, which is also confusing. Maybe we
should consider deprecating that at the same time?

Overall, I'm definitely in favour of this simplification.

Regards,

--
Rowan Tommins
[IMSoP]

BohwaZ/PHP

4 years ago

This RFC is confusing two different things:

1. variables inside strings (options 1, 2, 3)
2. dynamic variables names (option 4)

The 4th one is very useful.

$v = ${'param_' . $name};

There is no other practical way to do that, so removing that feature
would mean breaking something useful with no replacement.

Also why break something that works and is used?

If it feels too confusing, you could just deprecate use of the "${...}"
syntax inside strings, but still I don't feel like it's very confusing
and would bring more hassle that it's worth (a bit like the 8.1
depreciation of null for string functions, it's such a pain to deal
with).

Lynn

4 years ago

On Sat, Mar 12, 2022 at 3:11 AM BohwaZ <php@bohwaz.net> wrote:

> This RFC is confusing two different things:
>
> 1. variables inside strings (options 1, 2, 3)
> 2. dynamic variables names (option 4)
>
> The 4th one is very useful.
>
> $v = ${'param_' . $name};
>

Please don't ever ever ever write code like that!

> There is no other practical way to do that, so removing that feature
> would mean breaking something useful with no replacement.
>

While it's still a problematic way of writing code, you can use arrays
instead:
`$v = $something['param_' . $name] ?? null;

This at least keeps all the issues to the scope of `$something`.

> Also why break something that works and is used?
>

Variable variables should be removed from PHP asap. It's 2022 and I still
encounter bugs due to this "working" in legacy applications.

Kamil Tekiela

4 years ago

+1 on removing variable variables as soon as possible.

Mike Schinkel

4 years ago

> On Mar 12, 2022, at 5:44 AM, Lynn <kjarli@gmail.com> wrote:
>
> Variable variables should be removed from PHP asap. It's 2022 and I still
> encounter bugs due to this "working" in legacy applications.

> On Mar 12, 2022, at 5:48 AM, Kamil Tekiela <tekiela246@gmail.com> wrote:
>
> +1 on removing variable variables as soon as possible.

Variable variables provide functionality[1] that if removed would force major rewrites of PHP applications that were architected in a way that depends on that functionality.

And while probably between 90% and 99% of the time when someone uses variable variables there are better alternatives, variable variables make certain code possible that would be impossible without them.

So, *assuming* removing variable variables is important enough to break any the existing code that uses it — sourcegraph.com reports[2] 162.2k examples of its use — PHP should at least add a function that would allow getting the variables value by name.  Something like `get_variable_value_by_name($name)` but hopefully with a less verbose name than I used in my example just now.

#jmtcw

-Mike

[1] https://stackoverflow.com/questions/16339658/php-variable-value-from-string <https://stackoverflow.com/questions/16339658/php-variable-value-from-string>
[2] https://sourcegraph.com/search?q=context:global+lang:php+%5B%5E:%5C%5C%5D%5C%24%5C%7B%5C%24++count:all&patternType=regexp <https://sourcegraph.com/search?q=context:global+lang:php+[^:\\]\$\{\$++count:all&patternType=regexp>

Lynn

4 years ago

On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel <mike@newclarity.net> wrote:

>
> Variable variables provide functionality[1] that if removed would force
> major rewrites of PHP applications that were architected in a way that
> depends on that functionality.
>

And while probably between 90% and 99% of the time when someone uses

> variable variables there are better alternatives, variable variables make
> certain code possible that would be impossible without them.
>

Do you have examples where this is the case? Using arrays is a compatible
replacement as far as I know, and I highly doubt these kinds of hacks are
necessary.

Mike Schinkel

4 years ago

> On Mar 14, 2022, at 3:20 PM, Lynn <kjarli@gmail.com> wrote:
>
> On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel <mike@newclarity.net <mailto:mike@newclarity.net>> wrote:
>
> Variable variables provide functionality[1] that if removed would force major rewrites of PHP applications that were architected in a way that depends on that functionality.
> And while probably between 90% and 99% of the time when someone uses variable variables there are better alternatives, variable variables make certain code possible that would be impossible without them.

> Do you have examples where this is the case?

Most of these things cannot be done without the functionality provided by variable variables. However a few are examples could be handled differently but would require significant rewrite to fix without a new get_value_from_variable_name() function.  Either way, these are just from the first few pages of those 162.2k results on SourceGraph.com <http://sourcegroup.com/>:

https://github.com/microsoft/sql-server-samples/blob/master/samples/development-frameworks/laravel/vendor/jeremeamia/SuperClosure/src/SerializableClosure.php#L200-L208 <https://github.com/microsoft/sql-server-samples/blob/master/samples/development-frameworks/laravel/vendor/jeremeamia/SuperClosure/src/SerializableClosure.php#L200-L208>
https://github.com/mockery/mockery/blob/master/library/Mockery/Generator/StringManipulation/Pass/MethodDefinitionPass.php#L151 <https://github.com/mockery/mockery/blob/master/library/Mockery/Generator/StringManipulation/Pass/MethodDefinitionPass.php#L151>
https://github.com/vlucas/phpdotenv/blob/master/tests/Dotenv/DotenvTest.php#L251 <https://github.com/vlucas/phpdotenv/blob/master/tests/Dotenv/DotenvTest.php#L251>
https://github.com/squizlabs/PHP_CodeSniffer/blob/master/src/Standards/PSR12/Tests/Classes/ClassInstantiationUnitTest.inc#L34-L38 <https://github.com/squizlabs/PHP_CodeSniffer/blob/master/src/Standards/PSR12/Tests/Classes/ClassInstantiationUnitTest.inc#L34-L384>
https://github.com/kanaka/mal/blob/master/impls/php/interop.php#L19 <https://github.com/kanaka/mal/blob/master/impls/php/interop.php#L19>
https://github.com/moodle/moodle/blob/master/mod/data/tests/lib_test.php#L1293 <https://github.com/moodle/moodle/blob/master/mod/data/tests/lib_test.php#L1293>
https://github.com/moodle/moodle/blob/master/mod/data/tests/generator_test.php?L105#L104 <https://github.com/moodle/moodle/blob/master/mod/data/tests/generator_test.php?L105#L104>
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/tests/Fixer/FunctionNotation/StaticLambdaFixerTest.php#L236 <https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/tests/Fixer/FunctionNotation/StaticLambdaFixerTest.php#L236>
https://github.com/phpipam/phpipam/blob/master/functions/PEAR/Net/Ping.php#L284 <https://github.com/phpipam/phpipam/blob/master/functions/PEAR/Net/Ping.php#L284>
https://github.com/api-platform/core/blob/main/src/Core/Annotation/ApiProperty.php#L154-L159 <https://github.com/api-platform/core/blob/main/src/Core/Annotation/ApiProperty.php#L154-L159>
https://github.com/wp-cli/wp-cli/blob/master/php/WP_CLI/Runner.php#L1285-L1287 <https://github.com/wp-cli/wp-cli/blob/master/php/WP_CLI/Runner.php#L1285-L1287>
https://github.com/phpmyadmin/phpmyadmin/blob/master/libraries/classes/Database/Qbe.php#L878-L879 <https://github.com/phpmyadmin/phpmyadmin/blob/master/libraries/classes/Database/Qbe.php#L878-L879>
https://github.com/PrestaShop/PrestaShop/blob/develop/classes/SpecificPrice.php#L474 <https://github.com/PrestaShop/PrestaShop/blob/develop/classes/SpecificPrice.php#L474>

> Using arrays is a compatible replacement as far as I know, and I highly doubt these kinds of hacks are necessary.

"Necessary" is a judgement call.  If you never do meta-programming in PHP then these _techniques_ — calling them "hacks" is a bit incendiary — would not ever seem necessary.

However if a developer does work on projects that by-requirement leverage meta-programming then variable variables are a tool in one's toolkit that one would be hobbled without.

An area where I have seen them required is in theming where the CMS or plugin vendor wants to make it easier on the themer by creating dynamically-named variables in scope and then including a PHP file intended to be used as a template, and the in other functions being able to access those dynamically-named variables.

Other areas are in developer tools written in PHP for PHP developers.

That said, are you objecting to the "variable variable" syntax, or more broadly to the ability to access the value of a variable given its name (as a new function could provide)?

-Mike

P.S. BTW, I agree that if a developer can avoid variable variables there would be doing themselves and future maintainers a big favor. I am only commenting because in rare cases variable variables provide a capability that you cannot achieved another way.  But if PHP provides that other way by way of a function then the only concern is BC breakage for those who have used the technique.

Guilliam Xavier

4 years ago

Hi Mike, Lynn, and Kamil; I feel like this sub-thread has derailed from the
initial topic... As already said, this RFC is *not* about the general
"variable variables" feature, but about *the `"${...}"` syntax inside
interpolated strings* (i.e. double-quoted or heredoc), which can be
rewritten to either `"{${...}}"` or `"{$...}"` (or even just `"$..."`)
depending on the `...` part (not necessarily a variable variable).
If you want to discuss variable variables (in general), I would suggest
creating a new separate thread.
Regards,

Rowan Collins

4 years ago

On 12 March 2022 02:11:38 GMT, BohwaZ <php@bohwaz.net> wrote:

>This RFC is confusing two different things:
>
>1. variables inside strings (options 1, 2, 3)
>2. dynamic variables names (option 4)
>
>The 4th one is very useful.
>
>$v = ${'param_' . $name};
>
>There is no other practical way to do that, so removing that feature
>would mean breaking something useful with no replacement.

I don't see anything in the RFC that would break that example. The RFC is *only* about how variables are interpolated *inside quoted strings*.

As pointed out in the RFC, this syntax looks the same but works subtly differently inside a string, such that (string)${foo} !== "${foo}" (one dereferences a constant, the other doesn't).

Full handling of variable-variables is available in the full interpolation syntax, "{$...}", so "{${foo}}" *does* give the same result as (string)${foo}, and "{${'param_' . $name}}" gives the same result as (string)${'param_' . $name}. https://3v4l.org/aRMaq

@Ilija It might be worth adding the above example to the RFC , to show that "Option 2" can actually do everything that the other options do and more.

Regards,

--
Rowan Tommins
[IMSoP]

BohwaZ/PHP

4 years ago

> The RFC is *only* about how variables are interpolated *inside quoted
> strings*.

Then it doesn't seem clear in the RFC that it's limited to variables
inside strings, maybe it should be made clearer that it's only proposed
to deprecate that syntax inside strings, and not the variables
variables feature :)

Rowan Collins

4 years ago

On 12 March 2022 11:30:15 GMT, BohwaZ <php@bohwaz.net> wrote:

>> The RFC is *only* about how variables are interpolated *inside quoted
>> strings*.
>
>Then it doesn't seem clear in the RFC that it's limited to variables
>inside strings

In not quite sure how you missed it, because the word "string" is there in the title, and several times in the Proposal section, and every single example is of a double-quoted string.

But as I said, an example showing that the syntax being kept does in fact support variable-variables might be a useful addition.

Regards,

--
Rowan Tommins
[IMSoP]

Ilija Tovilo

4 years ago

Hi everyone, thanks for the feedback! I'll be responding to everyone
in the same e-mail to minimize noise.

---

Hi Rowan

> I presume the intent here is that the engine will generate an
> E_DEPRECATED each time such a string is encountered. Do you know yet if
> that will be easy to implement? I think some simple string handling is
> built into the parser, so there may not be a single code path to look at.

I created an implementation just now to answer this question. Luckily
there is a single code path and it was easy to implement.
https://github.com/php/php-src/compare/master...iluuu1994:deprecate-dollar-curly-encaps-var?expand=1

> The other question which I'm sure lots of users will have when they see
> the deprecation is: How easy is it to adapt usages of the deprecated
> syntax to use the non-deprecated variants? I'm guessing it's not as
> simple as moving the $ sign, because as you point out the syntaxes have
> different semantics; is there a general rule that users and/or tools can
> use to generate correct replacements?

For option 3, it is as simple as moving the $ sign. It supports just two forms:

* `"${foo}"` -> `"{$foo}"`
* `"${foo[expr]}"` -> `"{$foo[expr]}"`

As for option 4, it can also be transformed to 2 but requires
additional curly braces.

* `"${expr}"` -> `"{${expr}}"`

I have not intended to create a migration tool so far but that's
something worth considering.

> A final thought is that I seem to remember a previous thread (from
> Nikita?) about the "$foo[bar]" syntax, which is also confusing. Maybe we
> should consider deprecating that at the same time?

I agree that the inconsistent syntax is unfortunate. In this case at
least it's more concise so it has some justification for being there.

> @Ilija It might be worth adding the above example to the RFC , to show that "Option 2" can actually do
> everything that the other options do and more.

Absolutely, I will do that.

---

Hi BohwaZ

> The 4th one is very useful.
>
> $v = ${'param_' . $name};

Like Rowan mentioned, the RFC does not propose to deprecate variable
variables, just variable variables as a form of string interpolation.
You'll still be able to use variable variables, even in strings, like
noted above, just as form 2.

---

Hi Andreas

> First of all it would make it much easier for me to see what impact this
> RFC has if there were any numbers in it of how many large-scale
> repositories on for example github are affected by this.

You're absolutely right. I will attempt to gather some numbers. For
option 3, I also think "not widely used" is just plain wrong. As for
option 4, I'm fairly confident it only exists by accident 95% of the
time.

> But on the other hand, and that's much more important to me, I am
> missing the part where you explain the concrete benefits of that
> deprecation for the evolution of the language.

Basically, I was planning on suggesting more powerful string
interpolation in 2020, what the RFC refers to as future scope. But
with there already being 4 different types of syntax I was afraid of
adding fuel to the fire and decided to clean up the existing syntax
first. It's not a technical problem, just a usability problem.

> at least for me - as long as something is not in the way of a new
> feature or a strategy we leave it as it is.

I think this comes down to personal opinion. IMO this mindset hinders
progress. Removing a feature from the language takes many years, which
is why I believe it's essential to remove the baggage every once in a
while. There are other languages that attempt to keep perfect backward
compatibility and they are universally criticized for being
complicated and confusing. There's no single one argument I can
provide here as this comes down to your personal view on where the
language is going in the next decade.

Ilija

BohwaZ/PHP

4 years ago

> > The 4th one is very useful.
> >
> > $v = ${'param_' . $name};
>
> Like Rowan mentioned, the RFC does not propose to deprecate variable
> variables, just variable variables as a form of string interpolation.
> You'll still be able to use variable variables, even in strings, like
> noted above, just as form 2.

Thanks for clarifying :)

Sounds good for me then :)

Mark Baker

4 years ago

On 12/03/2022 15:23, Ilija Tovilo wrote:

> You're absolutely right. I will attempt to gather some numbers. For
> option 3, I also think "not widely used" is just plain wrong. As for
> option 4, I'm fairly confident it only exists by accident 95% of the
> time.

Like Andreas, this is my biggest concern with the proposal: the lack of
actual figures for how many libraries will be affected b the change.
We've seen a lot of deprecations over the last year, and they always
create some degree of pain for library/toolchain maintainers. While
typically dismissed as "it's just a deprecation notice", and being
accused of creating a "storm in a tea cup" whenever we raise questions,
library maintainers are the ones who have to deal with the additional
work when end users raise issues against their repos becase of all the
notices they're nw seeing in their logs; who already have a lot of work
preparing for each new release; who are expected to have fully
eliminated any deprecations from their repos (or their dependencies) on
or before the GA release date. How much extra work and/or stress is it
going to give those who maintain the PHP ecosystem?

From the preparation work for the 8.0 release, there has barely been
breathing space over the last two years; dealing with null arguments
passed to internal functions, and other (not always docmented) changes,
those libraries/tools take a lot of work to maintain. And with so many
deprecations going into this release, I would like to see some risk
assessment undertaken on the affect that each deprecation RFC will have,
with some real figures for the number of repositories that require work
to prepare them for the release.

--
Mark Baker

_________
|.  \     \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

I LOVE PHP

Ilija Tovilo

4 years ago

Hi everyone

I have tried to address all the feedback I've received for the RFC to
deprecate the ${} string interpolation.
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

* I have added instructions on how to migrate from option 3/4 to option 2
* I have analized the top 1000 packagist repositories to see what
impact the RFC would have
* https://gist.github.com/iluuu1994/05427dd74100af8e41ebff3d4201742c
* Total option 3: 267, total option 4: 0
* I have created a script to migrate your code automatically
* https://gist.github.com/iluuu1994/72e2154fc4150f2258316b0255b698f2
* I have adjusted the deprecation message to differentiate between
option 3 and 4 (it now says "variable variables" for option 4).

Let me know if you have any other concerns or questions.

Ilija

Alain Williams

4 years ago

On Thu, Mar 17, 2022 at 06:18:38PM +0100, Ilija Tovilo wrote:

> Hi everyone
>
> I have tried to address all the feedback I've received for the RFC to
> deprecate the ${} string interpolation.
> https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

Could you please add, for the avoidance of doubt, that this will still work:

$foo = 'bar';
$baz = 'foo';

echo $$baz;     // generates bar
echo "$$baz";   // generates $foo

Yes: I know that you are talking about ${} but this is sufficiently messy that
clarity is needed.

Regards

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

Andreas Heigl

4 years ago

Hey Ilija.

On 11.03.22 18:13, Ilija Tovilo wrote:

> Hi everyone
>
> It's been a while. Hope you are doing well.
>
> Last year I sent an e-mail to the mailing about the current state of
> string interpolation in PHP. I have now created an RFC to better
> explain the current behavior and why it would make sense to
> deprecate/remove some of it.
>
> https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
>
> Previous thread:
> https://externals.io/message/111519
>
> Let me know what you think.

As I already stated on twitter[1] for me there are multiple things missing:

First of all it would make it much easier for me to see what impact this
RFC has if there were any numbers in it of how many large-scale
repositories on for example github are affected by this.

But on the other hand, and that's much more important to me, I am
missing the part where you explain the concrete benefits of that
deprecation for the evolution of the language.

In evolution everything is fine as it is unless it directly hinders the
forthcoming and development of new essential features. IN PHP that means
- at least for me - as long as something is not in the way of a new
feature or a strategy we leave it as it is.

Deprecating something in terms of raising a deprecation message in the
error log, means that something is going to go away in one of the next
versions. We are going to remove a feature because we have a strategy to
improve something in that part. Be it complexity in the source code or
replacing a functionality or speeding up the language.

But so far I can see none of these things to apply here. The only
argument that you are giving in the RFC are that they are "rarely
useful" (reminds me a bit of Jack Sparrows "Ah! But you have heard of
me") and that they are easily confused.

While the later argument would also speak for unifying the
needle/haystack parameter order it is also making an assumption. Which
is not backed by any statistics. How many bug reports do we have in the
bug tracker due to this "confusion"?

Also what is "useful" is always a rather subjective matter. Just because
I don't find feature X useful doesn't mean that others can't find it useful.

But what worries me the most is that your proposal to deprecate and
essentially remove some string features that have been in the language
for quite some time and have once been considered relevant is not giving
me an idea of how that will benefit the language itself. How that will
immediately allow us to improve the language. By either removing 20% of
code that we suddenly don't need to maintain any more or because it will
allow us to immediately implement feature X in PHP9.

And just removing something to allow a different RFC that "might" allow
proposing other stuff is premature optimization. We might be able to
need this feature, so let's tweak our code for that possibility right
now. Without knowing whether that might actually be happening. And we
should not remove features *now* just because someone at one point in a
future might want to do something.

So while I appreciate the idea of a cleaner API I will for sure vote
"no" on this RFC in it's current form.

My 0.02€

Cheers

Andreas


[1] https://twitter.com/heiglandreas/status/1502338172210065409

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

A.L.E.C

4 years ago

On 12.03.2022 09:42, Andreas Heigl wrote:

> First of all it would make it much easier for me to see what impact this
> RFC has if there were any numbers in it of how many large-scale
> repositories on for example github are affected by this.

I just checked my projects' vendor folders and I found a dozen or so
occurrences of option 3 and none of option 4. Plus a few of option 3 in
my projects' code (that I'm fixing right now). That includes some
popular packages.

That being said, I think I will be +1 on this RFC.

--
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

Ilija Tovilo

4 years ago

Hi everyone

There hasn't been any discussion on this RFC for two weeks. I think
most concerns have been voiced. The result of the vote will most
likely come down to the views on backwards compatibility vs cleaning
up old behavior. The RFC contains an impact analysis and a script to
fully migrate existing code.

So, unless new concerns are voiced I'd like to put this to a vote in a
couple of days.

Ilija

On Fri, Mar 11, 2022 at 6:13 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

Guilliam Xavier

4 years ago

Hi Ilija,

On Thu, Mar 31, 2022 at 2:27 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

> Hi everyone
>
> There hasn't been any discussion on this RFC for two weeks. I think
> most concerns have been voiced. The result of the vote will most
> likely come down to the views on backwards compatibility vs cleaning
> up old behavior. The RFC contains an impact analysis and a script to
> fully migrate existing code.
>
> So, unless new concerns are voiced I'd like to put this to a vote in a
> couple of days.
>
> > https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
>

Just 2 editorial remarks:
- at the start of the Proposal, the numbered list is rendered like a code
block (preformatted text)
- the last paragraph before the Conclusion starts with the sentence "The
braces switch from option 3 to 4 because braces are not allowed in option
3": both occurrences of "braces" here should be "parentheses" (or "round
brackets", VS "curly brackets")

Best,

--
Guilliam Xavier