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