Re: [RFC] Deprecate Backtick Operator (V2)

> 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