> On 9 Oct 2019, at 01:34, Björn Larsson <bjorn.x.lars...@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.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
>>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
