Re: [RFC] Deprecate Backtick Operator (V2)

> 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.