Re: [RFC] Deprecate Backtick Operator (V2)

> On 9 Oct 2019, at 01:34, Björn Larsson <bjorn.x.larsson@telia.com> wrote: > > Den 2019-10-08 kl. 20:22, skrev Stephen Reay: >> >>> On 9 Oct 2019, at 01:08, Björn Larsson <bjorn.x.larsson@telia.com> wrote: >>> >>> Den 2019-10-08 kl. 17:49, skrev Stephen Reay: >>>>> On 8 Oct 2019, at 22:21, Andreas Hennings <andreas@dqxtech.net> wrote: >>>>> >>>>> The problem with the backtick operator syntax is that it is an obscure >>>>> but innocent-looking syntax for something that can have a huge, >>>>> perhaps devastating, impact. >>>>> It is rare enough in the field (as far as regular packages and >>>>> applications are concerned) that you can spend 5 years working with >>>>> PHP without ever learning about it. When you see it for the first >>>>> time, you will be surprised that this actually executes the code like >>>>> shell_exec(). This kind of surprise can make you shiver, and will >>>>> leave a bad taste about the language. >>>>> >>>>> The "<?=" and "<?php" also should really have no >>>>> place in regular >>>>> application code outside of templates. If we were to design the >>>>> language from scratch (which we are not), we would surely not require >>>>> to start each file with a "<?php". It is like a vestigial organ >>>>> from >>>>> the olden days.. >>>>> But removing this in a BC-breaking way would be too costly atm.. >>>>> The only thing I could imagine here is to introduce a distinct type of >>>>> PHP file which does not require the initial "<?php", and where any >>>>> further php open or close tags are illegal. >>>>> >>>>> Back to the backtick: >>>>> If it was just about regular applications and packages, then I think >>>>> we should get rid of it to prevent the kind of nasty surprise and bad >>>>> taste I mentioned before. >>>>> >>>>> But as Zeev pointed out, this syntax might be more prevalent in admin >>>>> scripts, which might have been running on a server for ages and the >>>>> person who created them might no longer be around. Here the removal >>>>> would have an unpleasant impact. >>>>> >>>>> The surprise from seeing the backtick operator will differ depending >>>>> how you see the language: As an application language, as a shell >>>>> enhancement tool, or as a template engine? PHP can be all three of >>>>> that, but not every developer will think about it that way. >>>>> >>>>> -- Andreas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 8 Oct 2019 at 16:30, Chase Peeler <chasepeeler@gmail.com> wrote: >>>>>> On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis <r@roze.lv> wrote: >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Olumide Samson [mailto:oludonsexy@gmail.com] >>>>>>>> >>>>>>>> it should be deprecated for exec usage since they both do same >>>>>>>> thing >>>>>>> With that logic <?= should also be deprecated in favor of echo >>>>>>> because it >>>>>>> does the same thing and is hard to find in internet search engines (was >>>>>>> in >>>>>>> some other argument). >>>>>>> >>>>>>> >>>>>> And we should deprecate the "print" command, since it's the >>>>>> same as echo. >>>>>> We should deprecate 'printf', since you can just do 'echo >>>>>> sprintf' and, now >>>>>> that I think about it, we should deprecate sprintf as well, since you can >>>>>> just use vsprintf. It's a simple change too... sprintf($s,$a,$b,$c) >>>>>> => >>>>>> vsprintf($s,[$a,$b,$c]);. I'm just it can be done with just a simple >>>>>> regex >>>>>> search/replace. >>>>>> >>>>>> The fact that are SO many different ways to output text is REALLY confusing >>>>>> for new developers. I think it's imperative we fix all of these items >>>>>> RIGHT >>>>>> NOW. By doing so, I'm sure all the .NET developers that are talking >>>>>> smack >>>>>> about PHP will suddenly denounce c# and start using PHP as well! >>>>>> >>>>>> >>>>>>>> This isn't high cost breaking changes coz it has a verifiable, >>>>>>>> ready >>>>>>> alternative to upgrade to without huge Regex searches. >>>>>>> >>>>>>> Since `` are used for literal strings (for poorly chosen reserved words >>>>>>> as >>>>>>> field, table names (which happens from time to time)) in MySQL >>>>>>> (multiline) >>>>>>> queries I doubt there is a simple way to distinguish and replace >>>>>>> everything >>>>>>> to exec(). >>>>>>> >>>>>>> rr >>>>>>> >>>>>>> -- >>>>>>> PHP Internals - PHP Runtime Development Mailing List >>>>>>> To unsubscribe, visit: >>>>>>> http://www.php.net/unsub.php >>>>>>> >>>>>>> >>>>>> -- >>>>>> Chase Peeler >>>>>> chasepeeler@gmail.com >>>>> -- >>>>> PHP Internals - PHP Runtime Development Mailing List >>>>> To unsubscribe, visit: >>>>> http://www.php.net/unsub.php >>>>> >>>> If a server has “scripts” that work now, and there’s no admin involved >>>> maintaining it (i.e. updating said scripts) - how is this going to be a problem? If there’s no one >>>> to maintain the script, there’s equally no one to update to an entirely new version of PHP either. >>>> >>> Couldn't it be like that the hosting provider no longer >>> support old PHP versions and the application is forced >>> up to a new version? And maybe the customer don't >>> have any technical staff, but needs to rent it in. Then >>> the least hassle the better, minimising cost. >>> >>> I myself can back down to PHP 5.4 if I wanted to, but >>> not all hosting providers provides that luxury. I have >>> really appreciated the smooth upgrade path that PHP >>> 7.x has provided even if 7.2 needed some small extra >>> work. 7.0 migration was also pretty smooth, so if 8.0 >>> can repeat that it would be nice. >>> >>> r//Björn L >> Hi Björn, >> >> >> I just want to clarify, you’re imagining a scenario where someone (a) rents a server that >> they don’t have control over (i.e. shared hosting) and (b) has some application running on it that >> is dependent on running commands via backquotes which (c) is unmaintained/not being updated and (d) >> the person renting the server is not technical enough to ‘fix’ the program? >> >> Have I understood that correctly? >> >> >> Cheers >> >> Stephen >> > Hi, > > The scenario I was thinking about is a small company where > they don't have technical staff permanently employed, more > taking it in when needed for feature updates, maintenance, > PHP upgrades etc. And cost should be kept to a minimum, > especially if there no improvements for the end customer. > > The hosting provider offers a classic LAMP with basic support, > e.g. managing backups etc. And some hosting providers says > that yes, feel free to run your app on PHP 5.6 while others > say we no longer support it, we support PHP 7.1 as lowest > version. > > Cheers //Björn L > Hi Björn, Ok - I can see that, I’ve had my share of small on-demand clients too. So lets say this RFC passes, and from 8.0 (currently slated for ~12 to ~14 months away) the backtick is deprecated. Maybe the hosting company upgrades their minimum/single install to 8.0 some time in 2020, and this company’s site/app starts logging that backticks are deprecated. The RFC doesn’t lay out a timeline for removal, but given the current discussion it’s safe to assume it the eventual removal would only be voted through at a .0 release - so that means 9.0 minimum. The 7.x series will have lasted 5 years by the time 8.0 is released. Obviously that’s not a definitive timeline, but going by that rough guide, we’re talking about a feature that will become unavailable to use, in roughly 6 years time, and can in most cases can be fixed by calling an automated tool, once. I’m not saying breaking things for the sake of breaking them is a valid objective for any RFC - but I also don’t agree with those claiming there is “no benefit” to removing backtick support. Cheers Stephen