Please stay on topic. Thank you.
Sounded reasonable to me. At least for security.
On 11 February 2018 at 21:24, Stanislav Malyshev
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 thei
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 unde
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
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
Hi,
On Mon, Feb 12, 2018 at 3:16 PM, CHU Zhaowei 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 ad
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
On Mon, Feb 12, 2018 at 8:38 AM, Eli White 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 's
2018-02-12 15:38 GMT+01:00 Eli White :
> 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'
Hi,
> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Wednesday, February 7, 2018 11:51 PM
> To: Stanislav Malyshev ; PHP Internals
>
> Subject: Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka.
> system)libgd
>
> On 07.02.2018 at 21:04, Stani
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 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!
>
░░▄▄███░
░░▄▄░███
░░███▄░░
░░▄▄███░
░░▄▄░███
░░███▄░▄█▀░█
░░▀█░▄███▀▀░▀███
███▀▀░░▀▀▀█████▀
██░░▄░░░▀▀▄▄███░
▄█▄▄▀█░█▄██▄▄░▀░
░░░▄
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_ZxX
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 simpl
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
On Mon, Feb 12, 2018 at 1:43 PM, 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 f
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 pr
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
On 12 February 2018 05:50:56 GMT+00:00, Pedro Lacerda
wrote:
>Besides testing, may or may not be valuable expose a `__STRICT_TYPES__`
>constant.
I think adding this to the language would be very controversial, because it
opens up the ability to undermine the "caller decides" concept of the two
2018-02-12 18:05 GMT-03:00 Rowan Collins :
>
> I think adding this to the language would be very controversial, because
> it opens up the ability to undermine the "caller decides" concept of the
> two scalar type modes. People on this list have openly said that they would
> like to force users to c
22 matches
Mail list logo
