> On 9 Oct 2019, at 01:08, Björn Larsson <bjorn.x.lars...@telia.com> wrote:
>
> Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
>>
>>> On 8 Oct 2019, at 22:21, Andreas Hennings <andr...@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 <chasepee...@gmail.com> wrote:
>>>> On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis <r...@roze.lv> wrote:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Olumide Samson [mailto:oludons...@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
>>>> chasepee...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
