Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
Hi! > On 6 Oct 2019, at 02:44, Stanislav Malyshev 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 > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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 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 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 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 > > > > >
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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 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 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 > >
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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 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
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
> 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
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
Hi, Am 04.10.2019 um 17:45 schrieb Mark Randall: Hi Internals, I put forward the following RFC "Deprecate Backtick Operator (V2)" for discussion. https://wiki.php.net/rfc/deprecate-backtick-operator-v2 I believe it is at least worth a discussion as to the pros and cons of deprecating this functionality, especially in light of the existence of better described and more well-known functions exhibiting identical behaviour. Two more advantages of using shell_exec(): - you can override/mock shell_exec() in a namespace. You cannot do that with the "backtick operator". - in IDEs like PHPStorm, you can ctrl-click on the function name "shell_exec" to check what it does: see what the return value is, see a description, click the link to the manual. You can easily search for "other usages" (right-click "Find Usages"). You cannot do that with the "backtick operator". Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
> On 5 Oct 2019, at 11:34, Stanislav Malyshev 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 > smalys...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
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
