Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117307
MIME-Version: 1.0
References: <CAPyj-LDVVfrSx1B3DpW+VjOe78twZVbPsGRv+k96MJ=1A3vCAw@mail.gmail.com>
 <20220312031138.5e0669a4@platypus>
In-Reply-To: <20220312031138.5e0669a4@platypus>
Date: Sat, 12 Mar 2022 11:44:05 +0100
Message-ID: <CANS-=pfAvb2T9HS-+T-CpnUDnnbp-GgSeYnHCive+PRB_sJC5A@mail.gmail.com>
To: BohwaZ <php@bohwaz.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e264cd05da032152"
Subject: Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation
From: kjarli@gmail.com (Lynn)

--000000000000e264cd05da032152
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000e264cd05da032152--