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 PM Gina P. Banyard <intern...@gpb.moe> wrote:
> >>
> >> > It is this time of year again where we proposed a list of
> >> > 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:
> >>
> >> > Deprecate backticks as an alias for shell_exec
> >>
> >> I think this might be too big BC break that might impact many scripts
> >> - would be good to see also if it impacts OSS projects. I guess it
> >> will impact even more non public code bases.
> >
> > Indeed, I use this *all the time* in quick hacky shell scripts in PHP.
> > Best practise? Definitely not. But it certainly is very useful.
>
> 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.)
>
> --Larry Garfield
>
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 = shell`git describe --abbrev=0 --match=dev* --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');
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 = 'PHP-Parser';
$version = '5.5.0';
$hash =
'sha384-vyGSwY5XXGRpPplN6utmy1kOiFBeqy79G0BRG8CnfT8AvHx7TBb99HFHkUEcXSs3';
$res =
cas`https://github.com/nikic/{$name}/archive/v{$version}.tar.gz#sri={$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 = `....`;
$result1 = tagRed$untagged;
$result2 = 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.
Just my 2 cents.
-- hakre
