Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107410
MIME-Version: 1.0
References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c9uXdqJsTizLCca-AswenZDv9-6yw=ranATp3XoutHyxw@mail.gmail.com>
 <DM5PR06MB285747B847DE2D7320758C05DE9A0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk>
In-Reply-To: <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk>
Date: Tue, 8 Oct 2019 11:09:06 +0200
Message-ID: <CAG9XoMR9DhKDwS1moH_9pjDNyZQ70ER5_stNs_GxQFucZ+ar7A@mail.gmail.com>
To: Lester Caine <lester@lsces.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000de5ab70594628504"
Subject: Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000de5ab70594628504
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Which is why ANY unnecessary changes that need to be made as a
> result are just painful often without ANY gain what so ever on either
side?

One gain that's very often overlooked on this list, is teaching a better
PHP to new generations. It IS confusing if PHP has more than one way to do
one thing, and if one of them is considered better than the other nowadays,
the other should be deprecated so that NEW code doesn't use it. Unless I
missed something, nobody in this thread has mentioned REMOVING backticks,
just DEPRECATING them. You don't HAVE to follow the deprecation with a
removal, at least not in a near future. But by deprecating the feature, at
least you're stopping the bleeding and (mostly) avoiding new code being
written that uses the legacy feature. Otherwise we'll have this discussion
again in 20 years, with the same outcome.

=E2=80=94 Benjamin


On Tue, 8 Oct 2019 at 10:47, Lester Caine <lester@lsces.uk> wrote:

> On 08/10/2019 04:31, Theodore Brown wrote:
> > In 8 of these, the backtick uses are exclusively in test files or other
> > scripts not part of the library source code. Then there are 11 packages
> > with one or two uses each, and only 2 packages with more than two
> occurrences.
> >
> > Raw numbers:
> https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34
>
> The question that has to be asked here is how many legacy projects have
> actually been moved to 'new' services like github, or even use code
> management anyway. The vast majority of third party hosting is simply
> based on isolated file management and even running clean-up tools are
> not going to be easy. Especially where the original author who set up
> the website is no longer around. While some hosts are maintaining the
> old versions of PHP, more often these days the big players are buying up
> small outfits and moving customers to new setups often without adequate
> care. Which is why ANY unnecessary changes that need to be made as a
> result are just painful often without ANY gain what so ever on either sid=
e?
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - https://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000de5ab70594628504--