Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117313
MIME-Version: 1.0
References: <CAPyj-LDVVfrSx1B3DpW+VjOe78twZVbPsGRv+k96MJ=1A3vCAw@mail.gmail.com>
 <20220312031138.5e0669a4@platypus> <A0E06DE1-3F3A-4E1A-B2E7-BBB2B4E35E26@gmail.com>
 <20220312123015.3713538b@platypus> <492ECA79-EC68-4BEB-AD67-B26A1D68D399@gmail.com>
In-Reply-To: <492ECA79-EC68-4BEB-AD67-B26A1D68D399@gmail.com>
Date: Sat, 12 Mar 2022 15:23:25 +0100
Message-ID: <CAPyj-LBk+hwQ3KreV-yi7k9nXqZEd8S86j12qSp3tUeKNy8wOA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation
From: tovilo.ilija@gmail.com (Ilija Tovilo)

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