Welcome! Log In Create A New Profile

Advanced

[PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Posted by Wes 
Hello PHPeople, I present to you... the shortest RFC ever.

https://wiki.php.net/rfc/deprecate-backtick-operator

Let me know what you think!
Stanislav Malyshev
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 11, 2018 09:10PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Stanislav Malyshev
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 11, 2018 09:30PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael Morris
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 05:50AM
On Sun, Feb 11, 2018 at 1:41 PM, Wes <[email protected]> wrote:

> 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.
Thomas Hruska
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 07:30AM
On 2/11/2018 9:45 PM, Michael Morris wrote:
> 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.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Please stay on topic. Thank you.
Midori Koçak
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 10:20AM
Sounded reasonable to me. At least for security.

On 11 February 2018 at 21:24, Stanislav Malyshev <[email protected]>
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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Lester Caine
[PHP-DEV] Tidying out of context errors
February 12, 2018 11:10AM
On 12/02/18 06:19, Thomas Hruska wrote:
> On 2/11/2018 9:45 PM, Michael Morris wrote:
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrey Andreev
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 12:50PM
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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
Andrey Andreev
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 03:00PM
Hi,

On Mon, Feb 12, 2018 at 3:16 PM, CHU Zhaowei <[email protected]> wrote:
> 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.

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


On Mon, Feb 12, 2018 at 8:16 AM, CHU Zhaowei <[email protected]> wrote:

> 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
Michael Morris
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 03:50PM
On Mon, Feb 12, 2018 at 8:38 AM, Eli White <[email protected]> wrote:

> 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.
Kalle Sommer Nielsen
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 04:40PM
2018-02-12 15:38 GMT+01:00 Eli White <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 ¯\_(ツ)_/¯
On Sun, Feb 11, 2018 at 2:41 PM, Wes <[email protected]> wrote:
> Hello PHPeople, I present to you... the shortest RFC ever.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator
>
> Let me know what you think!
>
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▄▄███░░░░░
░░▄▄░░░░░░░░░░░░░░░░░░░░░░░░░███████░░░░
░░███▄░░░░░░░░░░░░░░░░░░░░░▄█████▀░█░░░░
░░▀█████▄▄▄▄▀▀▀▀▀▀▀▀░▄▄▄▄▄███▀▀░▀███░░░░
░░░░███▀▀░░░░░░░░░░░░░░▀▀▀███░░░░██▀░░░░
░░░░██░░░░░░▄░░░░░░░░░░░░░░░▀▀▄▄███░░░░░
░░░░▄█▄▄████▀█░█▄██▄▄░░░░░░░░░████▀░░░░░
░░░▄████████░░░██████▄▄▄▄░░░░░████░░░░░░
░░░███░█░▀██░░░▀███░█░░███▄▄░░░░▀█░░░░░░
░░░████▄███▄▄░░░███▄▄▄█████▀░░░░░██░░░░░
░░▄████▀▀░▀██▀░░░▀█████████░░░░░░██░░░░░
░░▀███░░░▄▄▀▀▀▄▄░░░░▀██████░░░░░░░█░░░░░
░░░███░░█░░░░░░░▀░░░░▀███▀░░░░░░░░█░░░░░
░░░████▄▀░░░░░░░░▀░░░████▄░░░░░░░░░█░░░░
░░░██████▄░░░░░░░░░▀▀████▀░░░░░░░░░█░░░░
░░▄█████████▀▀▀▀░░░░░░░░░░░░░░░░░░░▀█░░░
░░███████████▄▄▄▄░░░░░░░░░░░░░░░░░░░█▄░░
░░████████▀▀▀▀▀▀░░░░░░░░░░░░░░░░░░░░░█▄░
░░████████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░█░
░▄███████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░░░█
░▀▀▀▀▀▀▀▀▀█▀▀▀░░░░░░░░░░░░░░░░░░░░░░░░░█
░░██░░░░██░░▄▄█████▄▄░░██████▄░███████░░
░░███▄░░██░▄██▀░░░▀██▄░██░░░▀████░░░░░░░
░░█████░█████░░░░░░░█████░░▄▄████▄▄▄▄▄░░
░░██░▀████▀██░░░░░░░██▀██████▀░██▀▀▀▀▀░░
░░██░░░███░▀██▄▄▄▄▄██▀░██░░░░░░██▄▄▄▄▄░░
░░▀▀░░░░▀▀░░░▀▀███▀▀░░░▀▀░░░░░░▀▀▀▀▀▀▀░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▄▄███░░░░░
░░▄▄░░░░░░░░░░░░░░░░░░░░░░░░░███████░░░░
░░███▄░░░░░░░░░░░░░░░░░░░░░▄█████▀░█░░░░
░░▀█████▄▄▄▄▀▀▀▀▀▀▀▀░▄▄▄▄▄███▀▀░▀███░░░░
░░░░███▀▀░░░░░░░░░░░░░░▀▀▀███░░░░██▀░░░░
░░░░██░░░░░░▄░░░░░░░░░░░░░░░▀▀▄▄███░░░░░
░░░░▄█▄▄████▀█░█▄██▄▄░░░░░░░░░████▀░░░░░
░░░▄████████░░░██████▄▄▄▄░░░░░████░░░░░░
░░░███░█░▀██░░░▀███░█░░███▄▄░░░░▀█░░░░░░
░░░████▄███▄▄░░░███▄▄▄█████▀░░░░░██░░░░░
░░▄████▀▀░▀██▀░░░▀█████████░░░░░░██░░░░░
░░▀███░░░░░██░░░░░░▀██████░░░░░░░█░░░░░░
░░░███░░▄▄▄▄▄▄▄▄░░░░▀███▀░░░░░░░░█░░░░░░
░░░████▄░░░░░░░░░░░░░████▄░░░░░░░░░█░░░░
░░░██████▄░░░░░░░░░▀▀████▀░░░░░░░░░█░░░░
░░▄█████████▀▀▀▀░░░░░░░░░░░░░░░░░░░▀█░░░
░░███████████▄▄▄▄░░░░░░░░░░░░░░░░░░░█▄░░
░░████████▀▀▀▀▀▀░░░░░░░░░░░░░░░░░░░░░█▄░
░░████████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░█░
░▄███████▄▄░░░░░░░░░░░░░░░░░░░░░░░░░░░░█
░▀▀▀▀▀▀▀▀▀█▀▀▀░░░░░░░░░░░░░░░░░░░░░░░░░█
░░░░░░░░░░░░▄▄█████▄▄░░░██░░░░███░░░░░░░
░░░░░░░░░░░▄██▀░░░▀██▄░░██░░░███░░░░░░░░
░░░░░░░░░░███░░░░░░░███░██░░███░░░░░░░░░
░░░░░░░░░░░██░░░░░░░██▀░█████░░░░░░░░░░░
░░░░░░░░░░░▀██▄▄▄▄▄██▀░░██░░██░░░░░░░░░░
░░░░░░░░░░░░░▀▀███▀▀░░░░██░░░░██░░░░░░░░
Stanislav Malyshev
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 08:20PM
Hi!

On 2/12/18 10:26 AM, Wes wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
David Rodrigues
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 09:40PM
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" <[email protected]> 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.
>
Michael Morris
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 12, 2018 09:40PM
On Mon, Feb 12, 2018 at 1:43 PM, Wes <[email protected]> wrote:

> 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.
On 12/02/18 20:43, Wes wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/12/2018 11:43 AM, Wes wrote:
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes Schlüter
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 13, 2018 03:40PM
On Mo, 2018-02-12 at 14:36 -0600, Michael Morris wrote:
> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 13, 2018 07:30PM
Aren't those different AST nodes?

On 13 Feb 2018 15:34, "Johannes Schlüter" <[email protected]> wrote:

> On Mo, 2018-02-12 at 14:36 -0600, Michael Morris wrote:
> > 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Mon, Feb 12, 2018 at 3:35 PM, David Rodrigues <[email protected]> wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Rowan Collins
Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator
February 14, 2018 12:10AM
On 13 February 2018 22:41:54 GMT+00:00, Wes <[email protected]> wrote:
>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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login