> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
