Re: [PHP-DEV] RFC karma for 'imsop' please

Morning Rowan, Granted. Cheers Joe On Wed, Jan 25, 2017 at 7:37 PM, Rowan Collins wrote: > Hi All, > > I would like to propose an RFC to deprecate some extremely old PHP > behaviour, but would like to draft the RFC before starting the discussion > so I can pre-empt

[PHP-DEV] Re: Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

On 01/25/2017 01:16 PM, Jacob Champion wrote: rather than dumping yet another httpd functional change on PHP-FPM and saying "here you go, deal with it" ("rather than *us* dumping", I should have said.) This was a confusing way for me to communicate "I don't want to just push breaking changes

[PHP-DEV] Re: Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

On 01/17/2017 06:44 AM, David Zuelke wrote: What's the right place for this discussion? Would somebody with the right karma/experience be willing to sign up to https://httpd.apache.org/lists.html#http-dev and join in? Or does a GitHub issue or PR suffice? Bump. I'm one of the httpd committers

[PHP-DEV] RFC karma for 'imsop' please

Hi All, I would like to propose an RFC to deprecate some extremely old PHP behaviour, but would like to draft the RFC before starting the discussion so I can pre-empt some likely queries about the proposal. Could I please have RFC karma for my wiki account "imsop"? Thanks, -- Rowan Collins

Re: [PHP-DEV] Class Constant Finalization

On 25/01/2017 08:49, Niklas Keller wrote: 2017-01-25 9:27 GMT+01:00 Wes : They don't belong to a class only, but to a class and all its descendants. Ideally, descendants should not inherit constants (or anything static), but we can't change that now, so final could make

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-01-24

Results for project PHP master, build date 2017-01-24 20:28:50-08:00 commit: e7166d1 previous commit:7cba315 revision date: 2017-01-24 18:00:08+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Re: String to array odd behaviour in 7.1

On 25.01.2017 at 14:21, Giovanni Giacobbi wrote: > Greetings, > > There is something weird with 7.1 and implicit strings to array > conversions, so I wanted to double check with you that the behaviour is > wanted (and perhaps the migration71 doc should be updated to reflect this. > > So in the

[PHP-DEV] String to array odd behaviour in 7.1

Greetings, There is something weird with 7.1 and implicit strings to array conversions, so I wanted to double check with you that the behaviour is wanted (and perhaps the migration71 doc should be updated to reflect this. So in the migration docs [1] you say that: " Applying the empty index

[PHP-DEV] Re: [PHP] test/list DMARC issues

On 23.01.2017 at 19:14, Richard wrote: >> Date: Monday, January 23, 2017 18:21:49 +0100 >> From: "Christoph M. Becker" >> >> On 22.01.2017 at 19:53, Richard wrote: >> >>> One of the issues that some people may be encountering is that this >>> mailing list's software doesn't

Re: [PHP-DEV] imap_fetchbody() leaks memory

On 24/01/17 08:41, Leon Sorokin wrote: > On 1/23/2017 2:45 PM, Michael Wallner wrote: >> Just assigned that to me, I'll try to come to it the next few days. > > Great, thanks! > Hi, I've updated the bug: https://bugs.php.net/bug.php?id=73493 TL;DR The c-client lib performs a lot of caching;

Re: [PHP-DEV] Class Constant Finalization

2017-01-25 9:27 GMT+01:00 Wes : > They don't belong to a class only, but to a class and all its descendants. > Ideally, descendants should not inherit constants (or anything static), but > we can't change that now, so final could make sense here. Basically, they > should work

Re: [PHP-DEV] Class Constant Finalization

They don't belong to a class only, but to a class and all its descendants. Ideally, descendants should not inherit constants (or anything static), but we can't change that now, so final could make sense here. Basically, they should work exactly like static fields, except that static fields can be

Re: [PHP-DEV] Class Constant Finalization

Hi! >> Given that we can now declare a class constant as public, protected, or >> private, can we also declare them final in 7.2? > > That doesn't make much sense to me. Constant belongs to a class. I don't > see much utility in "no class extending from this one can define > constant with the

Re: [PHP-DEV] Class Constant Finalization

Hi! > Given that we can now declare a class constant as public, protected, or > private, can we also declare them final in 7.2? That doesn't make much sense to me. Constant belongs to a class. I don't see much utility in "no class extending from this one can define constant with the same name".