Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
Hi!
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
I think we need a bit more explanation that that. Why would we want to
use backticks for Unicode strings? Why we need to deprecate existing
functionality for that - aren't there other alternatives that do not
require it?
Also, it does not spell out what you mean by "deprecate" - would it be
just a line in documentation? An warning/error message? Something else?
"Backward Incompatible Changes" seems to be incorrect - if you plan to
remove backticks or change its meaning at some stage, it certainly will
impact scripts that use it. Even if it's just an error message, it can
fail tests and cause other incompatible behavior.
Stas Malyshev
smalyshev@gmail.com
Hi Stas thanks for the feedback. I've added more info for more clarity.
It's absolutely impossible to treat notices as errors in PHP, so I assume
everybody thinks the same. If someone converts notices to ErrorExceptions
or something, it's their fault.
A notice in tests is exactly what a deprecation is supposed to do, force
people to update their code.
Regarding the notice level, it's a bit confusing picking one. E_DEPRECATED,
E_STRICT, E_NOTICE... I'm not sure what it should be.
Hi!
It's absolutely impossible to treat notices as errors in PHP, so I
assume everybody thinks the same. If someone converts notices to
ErrorExceptions or something, it's their fault.
A notice in tests is exactly what a deprecation is supposed to do, force
people to update their code.
If you force people to do something, by definition it is not "Backwards
Incompatible Changes: None". If it were none, people would not be forced
to do anything.
Regarding the notice level, it's a bit confusing picking one.
E_DEPRECATED, E_STRICT, E_NOTICE... I'm not sure what it should be.
You should write all the details in the RFC. If you are not sure what to
choose, write "I am not sure which one to choose here, options are X, Y
and Z".
Stas Malyshev
smalyshev@gmail.com
Sounded reasonable to me. At least for security.
On 11 February 2018 at 21:24, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
It's absolutely impossible to treat notices as errors in PHP, so I
assume everybody thinks the same. If someone converts notices to
ErrorExceptions or something, it's their fault.
A notice in tests is exactly what a deprecation is supposed to do, force
people to update their code.If you force people to do something, by definition it is not "Backwards
Incompatible Changes: None". If it were none, people would not be forced
to do anything.Regarding the notice level, it's a bit confusing picking one.
E_DEPRECATED, E_STRICT, E_NOTICE... I'm not sure what it should be.You should write all the details in the RFC. If you are not sure what to
choose, write "I am not sure which one to choose here, options are X, Y
and Z".Stas Malyshev
smalyshev@gmail.com
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
-1, not that my vote matters, but huge -1.
Nothing of value is gained by doing this. If there is something of value in
doing this, or some far future feature this clears the way for, please
enlighten me. But from where I sit this does nothing but break code for no
reason. And yes, emitting E_DEPRECATED is a breaking issue for any code
base that prides itself in being about to run all it's units with E_ALL set.
If we are going to go about removing stupid operators in PHP, the current
use of @ as an error suppression operator is much higher on the list since
encourages people to write bad code by sweeping problems under the rug, and
removing it would allow the operator to be reassigned to use as an
annotation operator as seen in Java and other language. I'm not holding my
breath for that to be done either.
If we are going to go about removing stupid operators in PHP, the current
use of @ as an error suppression operator is much higher on the list since
encourages people to write bad code by sweeping problems under the rug
Or people don't like how PHP currently handles errors/warnings/notices
and would prefer to handle the messages themselves in the same context
of the running code (i.e. not in a global handler). I'd rather see the
@ operator become a "most recent" message collector instead of purely an
error suppressor. That way, the current behavior wouldn't change for
existing applications but users could start taking advantage of whatever
associated functionality is added.
There are also significant security issues that arise when NOT using the
@ operator.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
Please stay on topic. Thank you.
If we are going to go about removing stupid operators in PHP, the current
use of @ as an error suppression operator is much higher on the list
since
encourages people to write bad code by sweeping problems under the rug
Or people don't like how PHP currently handles errors/warnings/notices
and would prefer to handle the messages themselves in the same context
of the running code (i.e. not in a global handler). I'd rather see the
@ operator become a "most recent" message collector instead of purely an
error suppressor. That way, the current behavior wouldn't change for
existing applications but users could start taking advantage of whatever
associated functionality is added.There are also significant security issues that arise when NOT using the
@ operator.
This is another decisive area of PHP. YES I am still using @ to prevent
PHP wandering off on it's own, so I can properly handle things like 'end
of file', so I don't want the global error. Much of the push for typing
everything is pushing global errors when local path changes WITHIN the
class is much more appropriate. The 'most recent' error is how most
database error processing is handled, and in most cases the error
suppressed by @ is simply taking PHP out of line.
Switches to disable global messages are now in something of a mess and
adding more and more sources is of little help to the vast majority of
users. backtick probably comes into the style class and with people
Python for on machine script handling nowadays then removing access to
the machine for PHP scripts just seems another push that way? Just what
target area IS PHP supporting?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi,
I agree with the criticism towards the RFC contents raised so far.
It's obviously put together with as little effort as possible, and the
cheeky version number doesn't help either ... Treating the RFC process
as a joke doesn't get you support.
But that being said, I do support the proposal. I understand people
opposed to removing features for no reason, but nobody needs this to
be an operator, it's not a widely-used one, and we all know if it was
proposed for addition today it would have 0 chance of acceptance.
Also, I would go for E_DEPRECATED now + removal in 8.0 without further
future scope. IMO, it should be common sense to get rid of obsolete
features, and therefore the token doesn't need to be repurposed for
this to be a good idea.
Cheers,
Andrey.
Hello,
But that being said, I do support the proposal. I understand people
opposed to removing features for no reason, but nobody needs this to
be an operator, it's not a widely-used one, and we all know if it was
proposed for addition today it would have 0 chance of acceptance.
How do you conclude that this is not a widely-used one?
btw, you already hit the most important point. Why do we deprecate or remove feature for no good?
in case PHP decided in future to use backtick enclosed strings for Unicode strings
AFAIK, since PHP7, we have no plan for unicode string.
Best regards,
CHU Zhaowei
Hi,
Hello,
But that being said, I do support the proposal. I understand people
opposed to removing features for no reason, but nobody needs this to
be an operator, it's not a widely-used one, and we all know if it was
proposed for addition today it would have 0 chance of acceptance.How do you conclude that this is not a widely-used one?
Running shell commands in itself is not a common task, and I've only
seen the backtick operator in 10-year old spaghetti code.
btw, you already hit the most important point. Why do we deprecate or remove
feature for no good?
You say it's "no good" because its existence doesn't create a problem
in an obvious way, but by that logic we shouldn't ever touch anything
that doesn't wreak havoc - I don't agree with that.
We're not talking about a function that satisfies a very common need
and/or has no alternative. We're talking about an operator that 100%
replicates an existing function, without providing any benefits over
it (on the contrary, using the function makes the code more easily
understandable) and is thus built into the language itself for
practically no reason.
Cheers,
Andrey.
I'll chime in on the "What evidence do you have that this is not
widely-used" ... in fact, I have seen through my PHP career this used very
regularly, and training/workshop/class sessions at conferences still
regularly teach this as the 'standard way' to handle shell commands.
So I think that this would have a huge impact on existing code, and I am
similarly a huge -1. Is it funky that random backticks cause a shell
action to happen? Yes. But there are a million funky things about PHP,
and we strive for backward compatibility when at all possible. And there
is no direct gain/need to remove this feature.
Eli
Hello,
But that being said, I do support the proposal. I understand people
opposed to removing features for no reason, but nobody needs this to
be an operator, it's not a widely-used one, and we all know if it was
proposed for addition today it would have 0 chance of acceptance.How do you conclude that this is not a widely-used one?
btw, you already hit the most important point. Why do we deprecate or
remove feature for no good?in case PHP decided in future to use backtick enclosed strings for
Unicode stringsAFAIK, since PHP7, we have no plan for unicode string.
Best regards,
CHU Zhaowei
I'll chime in on the "What evidence do you have that this is not
widely-used" ... in fact, I have seen through my PHP career this used very
regularly, and training/workshop/class sessions at conferences still
regularly teach this as the 'standard way' to handle shell commands.So I think that this would have a huge impact on existing code, and I am
similarly a huge -1. Is it funky that random backticks cause a shell
action to happen? Yes. But there are a million funky things about PHP,
and we strive for backward compatibility when at all possible. And there
is no direct gain/need to remove this feature.Eli
Agreed. There are a lot of things in PHP that are easily overlooked and can
go unused, especially if all one ever does with it is web page generation.
PHP can be used for shell scripting, and I've used it extensively for that
since I don't know how to write bash scripts. I'd personally be rather
peeved if I had to rewrite all my shell scripts.
2018-02-12 15:38 GMT+01:00 Eli White eli@eliw.com:
I'll chime in on the "What evidence do you have that this is not
widely-used" ... in fact, I have seen through my PHP career this used very
regularly, and training/workshop/class sessions at conferences still
regularly teach this as the 'standard way' to handle shell commands.So I think that this would have a huge impact on existing code, and I am
similarly a huge -1. Is it funky that random backticks cause a shell
action to happen? Yes. But there are a million funky things about PHP,
and we strive for backward compatibility when at all possible. And there
is no direct gain/need to remove this feature.Eli
Same thoughts here, -1 on deprecation. I prefer to use backticks over
shell_exec() when writing code that does something simple.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
There is not much to say. You either agree with it or you don't. And I
wasn't trying to make fun of none of you. Sorry if you consider the version
number inappropriate ¯_(ツ)_/¯
Hi!
There is not much to say. You either agree with it or you don't. And I
That's not how consensus discussion process in RFCs should work. It's
not just throwing your opinion over the fence, because the response
would be https://www.youtube.com/watch?v=pWdd6_ZxX8c . And don't get me
wrong, having an opinion, including one different from any other people
in the community, is completely fine. But: if you want to introduce a
major change into a 20-year-old stable project, it can't be just
somebody's opinion. It should be much more than that. And to make it
much more than that there should be good argument why we need to do this
change and why doing this change is so much better than not doing it
that we have to spend time on it, bearing the migration costs of it,
dealing with updating code and documentation, etc. It may be obvious to
you, but explaining it to everyone else - sometimes repeatedly, and
dealing with objections properly - not just saying "ok, that's my
opinion, you either agree or don't" - is part of the work on the RFC
that needs to be done.
If the idea is not ready for this work, it's fine to have pre-RFC
discussion - on the list or on any other venue - to shape it out, gather
the ideas and support, figure out major possible objections and ways to
address them, etc. Or just put the idea on the list and see if anybody
else agrees, that sometimes happens too.
--
Stas Malyshev
smalyshev@gmail.com
Again, the reason is: in case in future PHP wants to use backticks for
unicode strings, like javascript.
If the community think it's feasible, in PHP 9, 10, whatever, it must be
deprecated asap.
If you think PHP should use a different syntax for unicode strings in
future, you vote no.
It's as simple as that. I am asking to reserve a particular syntax for
something that could be needed in some years.
I totally agree to deprecate and remove it in 8.0.
Some reasons:
It usage is very rare (actually, I don't remeber the last time that I see
that in use). Even in old codes.
It too could causes confusion with single-quote in some fonts, sizes and
styles.
Is more easy to identify shell_exec() than backtick usage, anyway.
It have exactly the same behaviour than shell_exec(). Do not need adapt
usage beyond of the replacement itself.
Some keyboard layouts (like mine, ABNT2) requires to press shift+backtick
key then space to print a single backtick. Other option is I print two
backticks at sametime (is what I do when I work with Markdown).
Backtick inside backtick requires a most rare slash backtick to escape it:
``` (actually, I even know if it works haha)
Bonus/curiosity: is hard to find the definition of backtick if you don't
know the name of this symbol in english. In portuguese it is called "acento
grave" (something like "grave accent").
The remotion of this "feature" will allow use the backtick character to
another thing futurely (which could be decided carefully). Or even unused
forever.
Em 12 de fev de 2018 5:43 PM, "Wes" netmo.php@gmail.com escreveu:
Again, the reason is: in case in future PHP wants to use backticks for
unicode strings, like javascript.
If the community think it's feasible, in PHP 9, 10, whatever, it must be
deprecated asap.
If you think PHP should use a different syntax for unicode strings in
future, you vote no.
It's as simple as that. I am asking to reserve a particular syntax for
something that could be needed in some years.
It too could causes confusion with single-quote in some fonts, sizes and
styles.Is more easy to identify
shell_exec()than backtick usage, anyway.It have exactly the same behaviour than
shell_exec(). Do not need adapt
usage beyond of the replacement itself.
Those reasons are enough to move my -1 to a -0.5 (meaning I'd consider
abstaining on a vote).
The argument about reserving foo for unicode strings in some
far-flung future don't hold any water.
A. We tried Unicode, it went poorly, and we learned that ext/intl does
the job quite well. As someone who put a lot of work into PHP 6, I
don't see a reason to change that assessment.
B. If we DID take a second stab at unicode, we have syntax for unicode
strings already, ( u"Unicody", b"Binaryish" ) which doesn't require
coopting syntax that's been around for most of the language's
lifetime.
-Sara
Consider that people dislike writing \strlen(), they will for sure dislike
writing u"string". Hence reassigning backticks to unicode strings seemed to
me like a possibility.
Consider that people dislike writing \strlen(), they will for sure
dislike
writing u"string". Hence reassigning backticks to unicode strings
seemed to
me like a possibility.
I think a lot of people would dislike writing all their strings in backticks as well. It may not even be that easy to type on some keyboard layouts; outside of coding, it's a pretty obscure character.
A prefix syntax also has the advantage that you can still have u'strong' and u"weak" variants, and it has precedent in other languages, whereas foo has a strong association with code (Perl, Markdown come to mind).
Regards,
--
Rowan Collins
[IMSoP]
Consider that people dislike writing \strlen(), they will for sure dislike
writing u"string". Hence reassigning backticks to unicode strings seemed to
me like a possibility.
Okay. However, in my opinion, it is a bad idea to suggest a deprecation
of a feature that might be used differently sometime in the future,
because if it will not, the deprecation doesn't make any sense. So,
YAGNI applies somehow.
Actually, for me the only valid argument to deprecate the backtick
operator is "because it is a shady way to execute a rare and dangerous
operation". I, personally, would make that the main reason for the
deprecation proposal, and would move the other arguments to the "future
scope" section.
--
Christoph M. Becker
Hi!
Actually, for me the only valid argument to deprecate the backtick
operator is "because it is a shady way to execute a rare and dangerous
operation". I, personally, would make that the main reason for the
deprecation proposal, and would move the other arguments to the "future
scope" section.
I don't think it is "shady" - it's a well-known syntax, and while shell
execution can indeed be dangerous in some scenarios, it is commonly used
in cli applications, and is not that rare there. I don't see a point in
deprecating it - it doesn't improve anything that I can see, only makes
extra work for people that are using it.
--
Stas Malyshev
smalyshev@gmail.com
Again, the reason is: in case in future PHP wants to use backticks for
unicode strings, like javascript.
If the community think it's feasible, in PHP 9, 10, whatever, it must be
deprecated asap.
If you think PHP should use a different syntax for unicode strings in
future, you vote no.
It's as simple as that. I am asking to reserve a particular syntax for
something that could be needed in some years.
Any particular reason why "unicode string" wouldn't work?
Trust me, everyone here has at least one feature or operator they would
like to see done differently (cough - namespace operator - \ - cough) but
the proverbial train left the station a long time ago.
No technical reason. Keep in mind that people dislike... a lot... writing
\strlen() (with the leading ) so I thought they would also dislike writing
u"unicode" or any other solution that uses more than 2 enclosing characters.
No technical reason. Keep in mind that people dislike... a lot... writing
\strlen() (with the leading ) so I thought they would also dislike writing
u"unicode" or any other solution that uses more than 2 enclosing characters.
My personal fix for that particular problem is simply use unicode IN
core and ditch mbstring. That is not going to happen before I pass on,
but hopefully some later version of PHP will not have to worry at all
about unicode ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Any particular reason why "
unicode string" wouldn't work?
Because this would be a BC break which is really hard to detect. People
might do this (i.e. while generating Markdown output or something about
shell scripting or ...) and this might on first sight produce a vlid
output.
johannes
Aren't those different AST nodes?
Any particular reason why "
unicode string" wouldn't work?Because this would be a BC break which is really hard to detect. People
might do this (i.e. while generating Markdown output or something about
shell scripting or ...) and this might on first sight produce a vlid
output.johannes
Again, the reason is: in case in future PHP wants to use backticks for
unicode strings, like javascript.
If the community think it's feasible, in PHP 9, 10, whatever, it must be
deprecated asap.
If you think PHP should use a different syntax for unicode strings in
future, you vote no.
It's as simple as that. I am asking to reserve a particular syntax for
something that could be needed in some years.
backtick to execute a shell command is fairly standard in unix shell
scripting.
JavaScript is not used for unix shell scripting, php is. Not commonly,
but I've used it more than once - especially when I already have a php
class that does something I need to do from a shell script. It's a lot
faster to write the shell script in PHP than to port the various shell
scripts to python.
There is no good reason to remove it, and use of a back tick for
executing shell commands has a long history in many scripting languages.
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▄▄███░░░░░
░░▄▄░░░░░░░░░░░░░░░░░░░░░░░░░███████░░░░
░░███▄░░░░░░░░░░░░░░░░░░░░░▄█████▀░█░░░░
░░▀█████▄▄▄▄▀▀▀▀▀▀▀▀░▄▄▄▄▄███▀▀░▀███░░░░
░░░░███▀▀░░░░░░░░░░░░░░▀▀▀███░░░░██▀░░░░
░░░░██░░░░░░▄░░░░░░░░░░░░░░░▀▀▄▄███░░░░░
░░░░▄█▄▄████▀█░█▄██▄▄░░░░░░░░░████▀░░░░░
░░░▄████████░░░██████▄▄▄▄░░░░░████░░░░░░
░░░███░█░▀██░░░▀███░█░░███▄▄░░░░▀█░░░░░░
░░░████▄███▄▄░░░███▄▄▄█████▀░░░░░██░░░░░
░░▄████▀▀░▀██▀░░░▀█████████░░░░░░██░░░░░
░░▀███░░░▄▄▀▀▀▄▄░░░░▀██████░░░░░░░█░░░░░
░░░███░░█░░░░░░░▀░░░░▀███▀░░░░░░░░█░░░░░
░░░████▄▀░░░░░░░░▀░░░████▄░░░░░░░░░█░░░░
░░░██████▄░░░░░░░░░▀▀████▀░░░░░░░░░█░░░░
░░▄█████████▀▀▀▀░░░░░░░░░░░░░░░░░░░▀█░░░
░░███████████▄▄▄▄░░░░░░░░░░░░░░░░░░░█▄░░
░░████████▀▀▀▀▀▀░░░░░░░░░░░░░░░░░░░░░█▄░
░░████████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░█░
░▄███████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░░░█
░▀▀▀▀▀▀▀▀▀█▀▀▀░░░░░░░░░░░░░░░░░░░░░░░░░█
░░██░░░░██░░▄▄█████▄▄░░██████▄░███████░░
░░███▄░░██░▄██▀░░░▀██▄░██░░░▀████░░░░░░░
░░█████░█████░░░░░░░█████░░▄▄████▄▄▄▄▄░░
░░██░▀████▀██░░░░░░░██▀██████▀░██▀▀▀▀▀░░
░░██░░░███░▀██▄▄▄▄▄██▀░██░░░░░░██▄▄▄▄▄░░
░░▀▀░░░░▀▀░░░▀▀███▀▀░░░▀▀░░░░░░▀▀▀▀▀▀▀░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▄▄███░░░░░
░░▄▄░░░░░░░░░░░░░░░░░░░░░░░░░███████░░░░
░░███▄░░░░░░░░░░░░░░░░░░░░░▄█████▀░█░░░░
░░▀█████▄▄▄▄▀▀▀▀▀▀▀▀░▄▄▄▄▄███▀▀░▀███░░░░
░░░░███▀▀░░░░░░░░░░░░░░▀▀▀███░░░░██▀░░░░
░░░░██░░░░░░▄░░░░░░░░░░░░░░░▀▀▄▄███░░░░░
░░░░▄█▄▄████▀█░█▄██▄▄░░░░░░░░░████▀░░░░░
░░░▄████████░░░██████▄▄▄▄░░░░░████░░░░░░
░░░███░█░▀██░░░▀███░█░░███▄▄░░░░▀█░░░░░░
░░░████▄███▄▄░░░███▄▄▄█████▀░░░░░██░░░░░
░░▄████▀▀░▀██▀░░░▀█████████░░░░░░██░░░░░
░░▀███░░░░░██░░░░░░▀██████░░░░░░░█░░░░░░
░░░███░░▄▄▄▄▄▄▄▄░░░░▀███▀░░░░░░░░█░░░░░░
░░░████▄░░░░░░░░░░░░░████▄░░░░░░░░░█░░░░
░░░██████▄░░░░░░░░░▀▀████▀░░░░░░░░░█░░░░
░░▄█████████▀▀▀▀░░░░░░░░░░░░░░░░░░░▀█░░░
░░███████████▄▄▄▄░░░░░░░░░░░░░░░░░░░█▄░░
░░████████▀▀▀▀▀▀░░░░░░░░░░░░░░░░░░░░░█▄░
░░████████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░█░
░▄███████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░░░█
░▀▀▀▀▀▀▀▀▀█▀▀▀░░░░░░░░░░░░░░░░░░░░░░░░░█
░░░░░░░░░░░░▄▄█████▄▄░░░██░░░░███░░░░░░░
░░░░░░░░░░░▄██▀░░░▀██▄░░██░░░███░░░░░░░░
░░░░░░░░░░███░░░░░░░███░██░░███░░░░░░░░░
░░░░░░░░░░░██░░░░░░░██▀░█████░░░░░░░░░░░
░░░░░░░░░░░▀██▄▄▄▄▄██▀░░██░░██░░░░░░░░░░
░░░░░░░░░░░░░▀▀███▀▀░░░░██░░░░██░░░░░░░░
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
I don't have much of an opinion yet on the issue (observing the
arguments in the discussion so far), but one thing which stuck out for
me from one other recently announced RFCs [1] was the additional thought
of automating the code change via migrations tools, etc.
No one likes to do things manually and getting support for code fixers
could be of help here.
cheers,
- Markus
[1] https://wiki.php.net/rfc/fallback-to-root-scope-deprecation