Re: [PHP-DEV] [RFC][VOTE] Precise session management

Hi Levi, On Sat, Mar 12, 2016 at 9:24 AM, Yasuo Ohgaki wrote: > > BC issue is not severe. Users' test scripts may find behavior changes, > but it does not affect session functionality in apps at all. (It > should not at least, if it does, it's bug) Additional note on this.

Re: [PHP-DEV] [RFC][VOTE] Precise session management

Hi Levi, On Sat, Mar 12, 2016 at 1:50 AM, Levi Morrison wrote: > On Wed, Mar 9, 2016 at 2:14 AM, Yasuo Ohgaki wrote: >> The RFC is >> https://wiki.php.net/rfc/precise_session_management >> The PR is >> https://github.com/php/php-src/pull/1734 >> >> I suppose

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

> > I'm still on the fence about this, but here's a patch for it: > https://github.com/php/php-src/compare/master...tpunt:deprecate-var Thank you so much Thomas! I have added your patch to the RFC. I really appreciate you taking the time to implement this. Regards, Colin

Re: [PHP-DEV] [RFC][VOTE] Precise session management

On Wed, Mar 9, 2016 at 2:14 AM, Yasuo Ohgaki wrote: > The RFC is > https://wiki.php.net/rfc/precise_session_management > The PR is > https://github.com/php/php-src/pull/1734 > > I suppose almost all questions and discussion is finished, but > if you have any, please

RE: [PHP-DEV] [RFC Discussion] "var" Deprecation

Hi! > Hello all, > > I have completed my initial draft of the RFC to deprecate "var" in favor of > "public": https://wiki.php.net/rfc/var_deprecation > > I would greatly appreciate any feedback on this RFC, especially with the > following: > > - Ensuring that all major arguments for & against

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

Thanks for your feedback ! Any other thoughts from anyone else on this ? On 10 March 2016 at 02:31, Björn Larsson wrote: > Hi, Thanks for clarifying. Think the RFC would benefit from having > some of these examples in it. I also had in mind that it's handy for >

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-03-11

Results for project PHP master, build date 2016-03-11 06:31:31+02:00 commit: d5cf1a1 previous commit:97a88fc revision date: 2016-03-10 17:11:42+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

Jakub Kubíček wrote on 11/03/2016 10:03: From the RFC: var is therefore a limited subset of public. No, this is wrong. `var` was here much much longer than `public`, therefore `var` is not a subset of public, but rather `public` is _an extension_ of `var`. This is like arguing based on

Re: Fw: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

On Fri, 2016-03-11 at 08:35 +0100, Dolf Schimmel, TransIP wrote: > They surely could. In fact that's how we've been doing it for a long > time now. But they also want to lock down things as much as possible. In > our case we decided to disallow PHP from doing any forking and put it in > a (noexec)

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

2016-03-11 12:03 GMT+02:00 Jakub Kubíček : > From the RFC: > > > > var is therefore a limited subset of public. > > > No, this is wrong. `var` was here much much longer than `public`, therefore > `var` is not a subset of public, but rather `public` is _an extension_ of >

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

On 11 March 2016 at 10:03, Jakub Kubíček wrote: > > - `var` can semantically also represent an internal dependency, as I have > described earlier An internal property should be `private`. The use of `var` in the specific project you referenced earlier should only be

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

>From the RFC: > var is therefore a limited subset of public. No, this is wrong. `var` was here much much longer than `public`, therefore `var` is not a subset of public, but rather `public` is _an extension_ of `var`. The keyword `var` is also unique for it's semantics in the later versions