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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
