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

4 years ago by Rowan Tommins — view source — reply

unread

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]

4 years ago by BohwaZ — view source — reply

unread

This RFC is confusing two different things:

variables inside strings (options 1, 2, 3)
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).

4 years ago by Lynn — view source — reply

unread

This RFC is confusing two different things:

variables inside strings (options 1, 2, 3)

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.

4 years ago by Kamil Tekiela — view source — reply

unread

+1 on removing variable variables as soon as possible.

4 years ago by Mike Schinkel — view source — reply

unread

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

+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

4 years ago by Lynn — view source — reply

unread

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.

4 years ago by Mike Schinkel — view source — reply

unread

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/:

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.

4 years ago by Guilliam Xavier — view source — reply

unread

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,

4 years ago by Rowan Tommins — view source — reply

unread

This RFC is confusing two different things:

variables inside strings (options 1, 2, 3)

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]

4 years ago by BohwaZ — view source — reply

unread

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 :)

4 years ago by Rowan Tommins — view source — reply

unread

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]

4 years ago by Ilija Tovilo — view source — reply

unread

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

4 years ago by BohwaZ — view source — reply

unread

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 :)

4 years ago by Mark Baker — view source — reply

unread

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

4 years ago by Ilija Tovilo — view source — reply

unread

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

4 years ago by Alain D D Williams — view source — reply

unread

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

4 years ago by Andreas Heigl — view source — reply

unread

Hey Ilija.

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

4 years ago by Aleksander Machniak — view source — reply

unread

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

4 years ago by Ilija Tovilo — view source — reply

unread

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

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.

Ilija

4 years ago by Guilliam Xavier — view source — reply

unread

Hi Ilija,

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

[RFC][Under discussion] Deprecate ${} string interpolation View as Markdown

-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net]

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]