Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

  107374
October 5, 2019 04:34 smalyshev@gmail.com (Stanislav Malyshev)
Hi!


Reading the justifications, I must say I do not find them very
convincing. Specifically:

> * Alternative functions exist which are more descriptive, easily understood, and more readily searchable (for example, many common Google
searches omit the “`” token entirely when searching). It is very easy to understand `` since it has analogues in other script languages, also searching for "php backtick" easily leads to PHP manual.
> Backticks are visually easily confused with single quotes despite exhibiting radically different behaviour.
In my font they are not even close. This sounds like calling to stop using letter O because it looks like 0. Maybe if it's a problem - use one of the many available programmer's fonts which solve such problems easily.
> It could be considered unintuitive that single quoted strings do not support variable substitution, but single backticks do.
This sounds like a non-sequitur - why a different syntactic construct would behave exactly like single quote?
> It could be considered unintuitive that backticks already rely on the safe-mode and disabled-function settings for shell_exec
Safe mode is dead, so I don't think it makes sense to address this. In general, the justifications look a bit thin, and very far from passing the bar that is necessary to justify BC break. Please note that "you have to read the manual to know all the options for a function" is not something unacceptable and certainly not grounds for removing the function. -- Stas Malyshev smalyshev@gmail.com
  107375
October 5, 2019 08:09 kjarli@gmail.com (Lynn)
Hi,

> * Alternative functions exist which are more descriptive, easily > understood, and more readily searchable (for example, many common Google > searches omit the “`” token entirely when searching). > > It is very easy to understand `` since it has analogues in other script
languages, also searching for "php backtick" easily leads to PHP manual.
>
This is true, if you know they are called a backtick. It's not a frequent used character in a lot of languages and to be honest, I don't even know what the name is in my own language. I only know the English name because I encountered it in PHP, and besides of markdown I never use this character. I agree with the point made in the RFC, if you're a new developer and you have no idea what this character is called, it's hard to find out what it is and what it does.
> > Backticks are visually easily confused with single quotes despite > exhibiting radically different behaviour. > > In my font they are not even close. This sounds like calling to stop > using letter O because it looks like 0. Maybe if it's a problem - use > one of the many available programmer's fonts which solve such problems > easily. >
Even then at times they can be hard to distinguish. My eyesight isn't the best anymore and without my glasses, I can't see the difference in the majority of fonts until I put them next to each other, so I can understand why it can be confusing. I think one of the most important things missing from the RFC, is that it reduces the complexity by removing a second way of doing something. I've had to write Ruby a couple of times (vagrant, capistrano), and the thing I struggled the most with, was that different guides used different notations that all ended up doing the same, which I did not know. This is something that makes me question why something can be done in two different ways, might result in extra searches and generally speaking causes more overhead for (new) developers; "Why is this example using `ls` and the other exec('ls')? What is the difference? Which one should I use? Are there benefits in using one over the other?" vs. "This is how it's done". I'm personally in favor of this RFC. It's easy to replace backticks by exec and it improves the developer experience, especially for new developers. For me this outweighs the BC break it will cause in the future, especially given it will be deprecated in 8.0 and thus gives developers an eternity to fix it. Regards, Lynn van der Berg
  107379
October 5, 2019 19:46 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> This is true, if you know they are called a backtick. It's not a
I think it's reasonable to expect some minimal level of knowledge from the user. We're not targeting infants in the kindergarten here. So while we aim to not present too many obstacles to the novice user, we can reasonably expect from them at least basic middle-school level knowledge and abilities - and occasional read of the documentation never killed anybody either. -- Stas Malyshev smalyshev@gmail.com
  107380
October 5, 2019 20:01 kjarli@gmail.com (Lynn)
> Hi! > > > This is true, if you know they are called a backtick. It's not a > > I think it's reasonable to expect some minimal level of knowledge from > the user. We're not targeting infants in the kindergarten here. So while > we aim to not present too many obstacles to the novice user, we can > reasonably expect from them at least basic middle-school level knowledge > and abilities - and occasional read of the documentation never killed > anybody either. >
Hi, I didn't know the name of this character until several years after I started PHP, and I only found out because a colleague pointed it out to me. I don't think it's a good idea to assume people know the name of this operator or known how to find it easily. Googling is a skill on its own that not everyone masters, as much as I'd like to see this in our field. I also don't see how school knowledge is important here, especially as I went to school and I did not learn about it there. Besides of this, there are also keyboard( layout)s that don't have a backtick character present. Regards, Lynn van der Berg
  107381
October 5, 2019 20:25 andreas@dqxtech.net (Andreas Hennings)
The first time I saw the backtick operator in code, I thought it must
be some kind of ancient alternative syntax for string literals.
(and no, I did not know that these are called "backticks")

When I learned that code "quoted" in this way is immediately executed
as shell commands, this seemed like a completely insane and reckless
language design.

In most projects, executing shell commands should be something rare,
and the few cases where it happens should be visible and searchable.

Perhaps a legitimate use case would be a file that is essentially a
shell script with some PHP sprinkled in.

But overall I think we should rather get rid of this feature.


On Sat, 5 Oct 2019 at 22:02, Lynn <kjarli@gmail.com> wrote:
> > > Hi! > > > > > This is true, if you know they are called a backtick. It's not a > > > > I think it's reasonable to expect some minimal level of knowledge from > > the user. We're not targeting infants in the kindergarten here. So while > > we aim to not present too many obstacles to the novice user, we can > > reasonably expect from them at least basic middle-school level knowledge > > and abilities - and occasional read of the documentation never killed > > anybody either. > > > > Hi, > > I didn't know the name of this character until several years after I > started PHP, and I only found out because a colleague pointed it out to me. > I don't think it's a good idea to assume people know the name of this > operator or known how to find it easily. Googling is a skill on its own > that not everyone masters, as much as I'd like to see this in our field. I > also don't see how school knowledge is important here, especially as I went > to school and I did not learn about it there. Besides of this, there are > also keyboard( layout)s that don't have a backtick character present. > > Regards, > Lynn van der Berg
  107382
October 5, 2019 23:04 oludonsexy@gmail.com (Olumide Samson)
I think something that deals with system commands should be highly obvious
and should not be allowed through shortcut syntax that made it easy to be
hidden amongst codes for many security reasons.

There's already a popular way without hidden syntax and which speaks of
itself in a verifiable way called "exec", I'm not saying we should have it
removed just because it isn't obviously popular or it doesn't affect
anything for now; my argument is since we are moving to Version 8 of PHP,
it should be deprecated for exec usage since they both do same thing and
exec is highly obvious as a command function.

This isn't high cost breaking changes coz it has a verifiable, ready
alternative to upgrade to without huge Regex searches.

Thanks,
Samson.

On Sat, Oct 5, 2019, 9:26 PM Andreas Hennings <andreas@dqxtech.net> wrote:

> The first time I saw the backtick operator in code, I thought it must > be some kind of ancient alternative syntax for string literals. > (and no, I did not know that these are called "backticks") > > When I learned that code "quoted" in this way is immediately executed > as shell commands, this seemed like a completely insane and reckless > language design. > > In most projects, executing shell commands should be something rare, > and the few cases where it happens should be visible and searchable. > > Perhaps a legitimate use case would be a file that is essentially a > shell script with some PHP sprinkled in. > > But overall I think we should rather get rid of this feature. > > > On Sat, 5 Oct 2019 at 22:02, Lynn <kjarli@gmail.com> wrote: > > > > > Hi! > > > > > > > This is true, if you know they are called a backtick. It's not a > > > > > > I think it's reasonable to expect some minimal level of knowledge from > > > the user. We're not targeting infants in the kindergarten here. So > while > > > we aim to not present too many obstacles to the novice user, we can > > > reasonably expect from them at least basic middle-school level > knowledge > > > and abilities - and occasional read of the documentation never killed > > > anybody either. > > > > > > > Hi, > > > > I didn't know the name of this character until several years after I > > started PHP, and I only found out because a colleague pointed it out to > me. > > I don't think it's a good idea to assume people know the name of this > > operator or known how to find it easily. Googling is a skill on its own > > that not everyone masters, as much as I'd like to see this in our field. > I > > also don't see how school knowledge is important here, especially as I > went > > to school and I did not learn about it there. Besides of this, there are > > also keyboard( layout)s that don't have a backtick character present. > > > > Regards, > > Lynn van der Berg > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107383
October 6, 2019 04:05 mo.mu.wss@gmail.com ("M. W. Moe")
do you think because it's short you'll lose your virginity. I am sorry
about the vulgarity; but your stand is stand is ridiculous.

On Sat, Oct 5, 2019 at 4:04 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> I think something that deals with system commands should be highly obvious > and should not be allowed through shortcut syntax that made it easy to be > hidden amongst codes for many security reasons. > > There's already a popular way without hidden syntax and which speaks of > itself in a verifiable way called "exec", I'm not saying we should have it > removed just because it isn't obviously popular or it doesn't affect > anything for now; my argument is since we are moving to Version 8 of PHP, > it should be deprecated for exec usage since they both do same thing and > exec is highly obvious as a command function. > > This isn't high cost breaking changes coz it has a verifiable, ready > alternative to upgrade to without huge Regex searches. > > Thanks, > Samson. > > On Sat, Oct 5, 2019, 9:26 PM Andreas Hennings <andreas@dqxtech.net> wrote: > > > The first time I saw the backtick operator in code, I thought it must > > be some kind of ancient alternative syntax for string literals. > > (and no, I did not know that these are called "backticks") > > > > When I learned that code "quoted" in this way is immediately executed > > as shell commands, this seemed like a completely insane and reckless > > language design. > > > > In most projects, executing shell commands should be something rare, > > and the few cases where it happens should be visible and searchable. > > > > Perhaps a legitimate use case would be a file that is essentially a > > shell script with some PHP sprinkled in. > > > > But overall I think we should rather get rid of this feature. > > > > > > On Sat, 5 Oct 2019 at 22:02, Lynn <kjarli@gmail.com> wrote: > > > > > > > Hi! > > > > > > > > > This is true, if you know they are called a backtick. It's not a > > > > > > > > I think it's reasonable to expect some minimal level of knowledge > from > > > > the user. We're not targeting infants in the kindergarten here. So > > while > > > > we aim to not present too many obstacles to the novice user, we can > > > > reasonably expect from them at least basic middle-school level > > knowledge > > > > and abilities - and occasional read of the documentation never killed > > > > anybody either. > > > > > > > > > > Hi, > > > > > > I didn't know the name of this character until several years after I > > > started PHP, and I only found out because a colleague pointed it out to > > me. > > > I don't think it's a good idea to assume people know the name of this > > > operator or known how to find it easily. Googling is a skill on its own > > > that not everyone masters, as much as I'd like to see this in our > field. > > I > > > also don't see how school knowledge is important here, especially as I > > went > > > to school and I did not learn about it there. Besides of this, there > are > > > also keyboard( layout)s that don't have a backtick character present. > > > > > > Regards, > > > Lynn van der Berg > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
  107385
October 6, 2019 13:18 r@roze.lv ("Reinis Rozitis")
> -----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 > 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
  107386
October 6, 2019 13:41 marandall@php.net (Mark Randall)
On 06/10/2019 14:18, Reinis Rozitis wrote:
> 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().
Hi, As the RFC states, there are already widely used tools available which can do this reliably: https://github.com/FriendsOfPHP/PHP-CS-Fixer backtick_to_shell_exec -- Mark Randall
  107419
October 8, 2019 14:29 chasepeeler@gmail.com (Chase Peeler)
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 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
  107420
October 8, 2019 15:21 andreas@dqxtech.net (Andreas Hennings)
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 "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 > 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
  107421
October 8, 2019 15:49 php-lists@koalephant.com (Stephen Reay)
> 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 " 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 " 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 " 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 >> 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.
  107422
October 8, 2019 18:08 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
> >> 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 "> 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 "> 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 "> 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 >>> 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. > 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
  107426
October 8, 2019 18:22 php-lists@koalephant.com (Stephen Reay)
> On 9 Oct 2019, at 01:08, Björn Larsson larsson@telia.com> wrote: > > Den 2019-10-08 kl. 17:49, skrev Stephen Reay: >> >>> 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 ">> 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 ">> 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 ">> 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 >>>> 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. >> > 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
  107428
October 8, 2019 18:34 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-10-08 kl. 20:22, skrev Stephen Reay:
> >> On 9 Oct 2019, at 01:08, Björn Larsson larsson@telia.com> wrote: >> >> Den 2019-10-08 kl. 17:49, skrev Stephen Reay: >>>> 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 ">>> 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 ">>> 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 ">>> 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 >>>>> 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. >>> >> 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
  107430
October 8, 2019 18:53 php-lists@koalephant.com (Stephen Reay)
> On 9 Oct 2019, at 01:34, Björn Larsson larsson@telia.com> wrote: > > Den 2019-10-08 kl. 20:22, skrev Stephen Reay: >> >>> On 9 Oct 2019, at 01:08, Björn Larsson larsson@telia.com> wrote: >>> >>> Den 2019-10-08 kl. 17:49, skrev Stephen Reay: >>>>> 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 ">>>> 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 ">>>> 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 ">>>> 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 >>>>>> 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. >>>> >>> 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
  107444
October 8, 2019 22:59 oludonsexy@gmail.com (Olumide Samson)
On Tue, Oct 8, 2019, 3:30 PM 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 > 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
If you feel you want all those functions deprecated in favor of any other, put up a RFC whenever you want to(No one is stopping you from that). I think that's been inconsistencies from the part of early contributors which is the same reason we are having "haystack and needle" problem and I'm not sure there's a problem fixing those old days mistake. The major issues I'm seeing now is that, those who did bring up those functions back then are the one leading the fight against correcting them, maybe it helps them stay relevant IDK.
  107445
October 8, 2019 23:26 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> If you feel you want all those functions deprecated in favor of any other, > put up a RFC whenever you want to(No one is stopping you from that).
That's part of the problem. RFC should be for something that is necessary and beneficial for the whole community, doubly and triply so when we're talking about BC breaks. It shouldn't be just "whatever I want, let me put it to a vote". RFCs are not a twitter poll where anybody can vote on anything and anything goes. It should be used responsibly, and if people don't understand this responsibility maybe it's too early for them to propose any RFCs. -- Stas Malyshev smalyshev@gmail.com
  107446
October 8, 2019 23:37 larry@garfieldtech.com ("Larry Garfield")
On Tue, Oct 8, 2019, at 6:26 PM, Stanislav Malyshev wrote:
> Hi! > > > If you feel you want all those functions deprecated in favor of any other, > > put up a RFC whenever you want to(No one is stopping you from that). > > That's part of the problem. RFC should be for something that is > necessary and beneficial for the whole community, doubly and triply so > when we're talking about BC breaks. It shouldn't be just "whatever I > want, let me put it to a vote". RFCs are not a twitter poll where > anybody can vote on anything and anything goes. It should be used > responsibly, and if people don't understand this responsibility maybe > it's too early for them to propose any RFCs. > > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
I hesitate to wade into this discussion at all, but I have to overall agree with Zeev and Stas. I'm a vocal proponent of PHP evolving, becoming "stricter" (whatever that means), more typing, adopting more modern/functional features, not being held back, blah blah blah. Normally I'm on the side of the language itself becoming more powerful. I... had actually forgotten that backticks existed until this thread, to be honest. I can't recall the last time I used them. But, on this point Zeev is correct: There are a few billion lines of PHP code in the wild, and we only know what's used in maybe a few million of them. That means the barrier for removing a feature needs be *really* high, and "it seems confusing" does not clear that bar. "If we were designing the language today we wouldn't do that" is also not a compelling argument. "Programming is like sex; make one mistake and support it for the rest of your life." (Anonymous.) That something is already implemented has a larger vote than whatever design preferences we may globally have. BC breakage in a language is a big frickin' deal. It should not be taken lightly, and "people don't know what to google for" is, frankly, very lightly. Overall, I see only three good arguments for BC breakage: 1) Security. 2) It's rarely used AND it conflicts with some other significant improvement. 3) It's rarely used AND it is a very common source of serious bugs (even if not technically security). (Note: Technically adding a new function or class is also a BC break as it reserves a new function/class name, and we should be cautious with those, but that's a lower threshold in my mind as it doesn't change existing behavior except in very narrow circumstances that will be immediately discovered and have a very natural way to address them.) There absolutely are issues that rise to that level. register_globals and magic quotes are the canonical examples, but the last minute change of random_int() to throw an exception rather than return false when it can't generate a true random value is also in that category. So far, I have not seen any arguments for deprecating/removing backticks that meet that criteria, nor data to suggest that they do. --Larry Garfield
  107447
October 8, 2019 23:38 marandall@php.net (Mark Randall)
On 09/10/2019 00:26, Stanislav Malyshev wrote:
> That's part of the problem. RFC should be for something that is > necessary and beneficial for the whole community, doubly and triply so > when we're talking about BC breaks. It shouldn't be just "whatever I > want, let me put it to a vote". RFCs are not a twitter poll where > anybody can vote on anything and anything goes. It should be used > responsibly, and if people don't understand this responsibility maybe > it's too early for them to propose any RFCs.
Might I request that you please stick to discussing the actual topic of the RFC, rather than trying to shift the conversation towards who can and cannot propose RFCs :-) If you want to discuss changing the RFC mechanics and who is entitled to make them, please make your own RFC. Thank you. Mark Randall
  107376
October 5, 2019 09:07 php-lists@koalephant.com (Stephen Reay)
> On 5 Oct 2019, at 11:34, Stanislav Malyshev <smalyshev@gmail.com> wrote: > > Hi! > >> https://wiki.php.net/rfc/deprecate-backtick-operator-v2 > > Reading the justifications, I must say I do not find them very > convincing. Specifically: > >> * Alternative functions exist which are more descriptive, easily > understood, and more readily searchable (for example, many common Google > searches omit the “`” token entirely when searching). > > It is very easy to understand `` since it has analogues in other script > languages, also searching for "php backtick" easily leads to PHP manual. > >> Backticks are visually easily confused with single quotes despite > exhibiting radically different behaviour. > > In my font they are not even close. This sounds like calling to stop > using letter O because it looks like 0. Maybe if it's a problem - use > one of the many available programmer's fonts which solve such problems > easily. > >> It could be considered unintuitive that single quoted strings do not > support variable substitution, but single backticks do. > > This sounds like a non-sequitur - why a different syntactic construct > would behave exactly like single quote? > >> It could be considered unintuitive that backticks already rely on the > safe-mode and disabled-function settings for shell_exec > > Safe mode is dead, so I don't think it makes sense to address this. > > In general, the justifications look a bit thin, and very far from > passing the bar that is necessary to justify BC break. Please note that > "you have to read the manual to know all the options for a function" is > not something unacceptable and certainly not grounds for removing the > function. > > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Hi Stas, all, I’m not overly for or against this change - I can see arguments both ways, but please keep in mind that the “other languages” argument works both ways: In php, shell/similar, ruby and perl, backticks are command substitution. This surely due to shared influence. In plenty of other languages they do very different things, from string literals, to interpolation/templates, escaping, identifier quoting, or even comments. Like I said, I can see arguments both ways, but use as a command substitution operator is hardly a universal thing. Cheers Stephen
  107378
October 5, 2019 19:44 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Like I said, I can see arguments both ways, but use as a command substitution operator is hardly a universal thing.
Nobody said it's "universal thing". Virtually nothing is "universal thing" among over 9000 programming languages that exist. I just claimed it's a common thing which reasonably experienced user have high chance of encountering and recognizing. Arguing that non-universality would be the reason to remove syntax from PHP is like arguing we should remove the use of whitespace because some languages have significant whitespace (like Python) and you can't google whitespace (especially if you don't know the word "whitespace") so clearly this is super-confusing and should be removed. I don't mean this as a personal criticism on the RFC author, who clearly took some thought about it and is entitled to his own opinions, but arguments like this look a bit ridiculous to me. We have tons of stuff to improve in PHP without messing with things that aren't broken and don't need any improvement at all, and will have high BC costs. -- Stas Malyshev smalyshev@gmail.com
  107384
October 6, 2019 05:21 php-lists@koalephant.com (Stephen Reay)
Hi!


> On 6 Oct 2019, at 02:44, Stanislav Malyshev <smalyshev@gmail.com> wrote: > > Hi! > >> Like I said, I can see arguments both ways, but use as a command substitution operator is hardly a universal thing. > > Nobody said it's "universal thing”.
I never claimed anyone said it’s universal. I simply said it isn’t universal.
> Virtually nothing is "universal > thing" among over 9000 programming languages that exist. I just claimed > it's a common thing which reasonably experienced user have high chance > of encountering and recognizing.
Ok, so of those 9000 programming languages how many use it for shell execution? So far I’m aware of PHP, Perl, Ruby and Shell. I would argue that this means those (first three) languages likely have a common inspiration from Shell, not that the feature is “common” amongst programming languages.
> Arguing that non-universality would be the reason to remove syntax from > PHP is like arguing we should remove the use of whitespace because some > languages have significant whitespace (like Python) and you can't google > whitespace (especially if you don't know the word "whitespace") so > clearly this is super-confusing and should be removed. >
Again, I wasn’t saying non-universality was “the reason” to remove the syntax. My point was that if *you* claimed it’s “common” amongst programming languages - and ignored that it’s used for *other, less dangerous* constructs in many more languages than it’s used for shell execution.
> I don't mean this as a personal criticism on the RFC author, who clearly > took some thought about it and is entitled to his own opinions, but > arguments like this look a bit ridiculous to me. We have tons of stuff > to improve in PHP without messing with things that aren't broken and > don't need any improvement at all, and will have high BC costs. > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >