Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128307
Content-Type: text/plain; charset=utf-8
Message-ID: <1753807300279.3679674018.1291915422@yahoo.de>
To: larry@garfieldtech.com
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Date: Tue, 29 Jul 2025 19:22:36 +0000
In-Reply-To: <46e0c98a-2003-442c-9f8f-16c8fa0476f0@app.fastmail.com>
References: <46e0c98a-2003-442c-9f8f-16c8fa0476f0@app.fastmail.com>
User-Agent: Vivaldi Mail/7.5.3735.56
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:

> On Mon, Jul 14, 2025, at 5:36 AM, Derick Rethans wrote:
> > On Thu, 3 Jul 2025, Jakub Zelenka wrote:
> >
> >> On Wed, Jul 2, 2025 at 10:00=E2=80=AFPM Gina P. Banyard <internals@gpb=
.moe> wrote:
> >>=20
> >> > It is this time of year again where we proposed a list of=20
> >> > deprecations to add in PHP 8.5:
> >> >
> >> > https://wiki.php.net/rfc/deprecations_php_8_5
> >>
> >> Here are few notes on the ones that I don't agree with:
> >>=20
> >> >  Deprecate backticks as an alias for shell_exec
> >>=20
> >> I think this might be too big BC break that might impact many =
scripts=20
> >> - would be good to see also if it impacts OSS projects. I guess it=20
> >> will impact even more non public code bases.
> >
> > Indeed, I use this *all the time* in quick hacky shell scripts in PHP.=
=20
> > Best practise? Definitely not. But it certainly is very useful.
>=20
> Is their use for quick hacky scripts worth the cost of reserving a symbol=
 that could be repurposed for something else more generally useful in the =
future?  (Not immediately of course, but eventually.)
>=20
> --Larry Garfield
>=20

This sounds quite negative to me which it is not in my book, IMHO best to =
have all three available in PHP, so you would have made the argument for me=
 to keep the symbol.

And thinking:

Symbol reuse could perhaps be possible already today with a prefix.

The backticks operator evaluates to a string (or a primitive that could be =
represented as a string), which is an interface to build upon. For example =
a "tagging"-function:

    $result =3D shell`git describe --abbrev=3D0 --match=3Ddev* --tags =
dev$ver^`;

    function shell($what, ...$not)
    : on_return_this_type_is_checked_by_the_script_interpreter
    {
        (random_int(0, 1))
        and throw new Error('To Return Never when it's due');
       =20
        return rtrim(shell_exec(something_with($what, 'and', $not)));
    }

This could also improve the current use, even immediately, and eventually =
helps to think out of the box.

    $name =3D 'PHP-Parser';
    $version =3D '5.5.0';
    $hash =3D 'sha384-vyGSwY5XXGRpPplN6utmy1kOiFBeqy79G0BRG8CnfT8AvHx7TBb99=
HFHkUEcXSs3';


    $res =3D cas`https://github.com/nikic/{$name}/archive/v{$version}.tar.=
gz#sri=3D{$hash}#`;

String is the universal interface.

My educated guess is that I don't need to explain the benefits of _template=
 literals_ over ordinary PHP string literals for Larry, but for those who =
are curious, this is inspired by EcmaScript and you can try it out in your =
browser or read on MDN about it. Not saying this should be the same syntax,=
 just going into the pink here. Maybe even recent ${'...'} vs. "{${'...'}}"=
 changes in interpolation opened up some room to come closer.

Now if only those backticks would become an aspect of the tag over the =
assignment so we could get "get hook semantics" on them at the time of =
tagged-use:

  $untagged =3D `....`;
  $result1 =3D tagRed$untagged;
  $result2 =3D tagBlue$untagged;

hmm...  not entirely compatible with the current behaviour I'd guess, but =
who knows, likely conflicts over conflicts in the LALR parser when we start=
 to tag $variable identifiers.=20

Just my 2 cents.

-- hakre