After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
On Fri, 2014-11-21 at 10:07 +0200, Zeev Suraski wrote:
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Morning Zeev,
Proposed
On 21 Nov 2014, at 03:02, Adam Harvey ahar...@php.net wrote:
The problem is that it’s the least bad of the available options.
I disagree. To my mind, the best option right now (barring the status
quo, which realistically I'd prefer) would be the try_* functions
only. They line up with
On 20/11/14 21:29, Rowan Collins wrote:
The problem is that the constructor is part of the public API (for
inheritance purposes) so the required refactoring is not necessarily isolated
to one project, or even doable by one developer. The maintainer of the
library must first release a
On 21/11/14 02:10, Yasuo Ohgaki wrote:
To be honest, I have mixed feeling for this FRC.
Stricter type check is good. However, it requires runtime cost.
One of the area where it is being held up as good practice is filtering
data which is then passed to a database. With best practice on handling
On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins pthre...@pthreads.org wrote:
On Fri, 2014-11-21 at 10:07 +0200, Zeev Suraski wrote:
After some Twitter hints that I should get my act together and finally
move
this to a vote, it’s finally happening:
On Fri, Nov 21, 2014 at 9:07 AM, Zeev Suraski z...@zend.com wrote:
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Hi,
could you update the timeline
Lester Caine wrote on 21/11/2014 09:49:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
fixing each and every warning simply to ensure
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
fixing each and every warning simply to
Zitat von Lester Caine les...@lsces.co.uk:
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
Hi,
I still don't get get what problem this RFC is actually going to solve?
I don't see a problem. Yes, PHP4 constructors are are old and should no
longer be used. But there is no problem still supporting them. Raise an
E_DEPRECATED for those, and be done with it.
+1
I can accept BC-breaks
On 21/11/14 12:36, Jan Schneider wrote:
Zitat von Lester Caine les...@lsces.co.uk:
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings
Lester Caine wrote on 21/11/2014 13:27:
No - There have been several threads on deprecating things that are
currently 'hidden' by e_strict. The confusion is created by having two
incompatible styles of coding, and unless one brings the 'non-e_strict'
code in to line with current practices it
On 21/11/14 14:15, Rowan Collins wrote:
Lester Caine wrote on 21/11/2014 13:27:
No - There have been several threads on deprecating things that are
currently 'hidden' by e_strict. The confusion is created by having two
incompatible styles of coding, and unless one brings the 'non-e_strict'
Kris,
This existed in the RFC since the get go and I don't believe anybody raised any
concerns about it. There was plenty of time for discussion. Either way
approval of this RFC won't have any effect on the approval or rejection of
other RFCs.
Kris, All - I'm now on a 7th day straight of a
On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Nov 21, 2014 at 9:07 AM, Zeev Suraski z...@zend.com wrote:
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
On Fri, Nov 21, 2014 at 4:18 PM, Zeev Suraski z...@zend.com wrote:
On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Nov 21, 2014 at 9:07 AM, Zeev Suraski z...@zend.com wrote:
After some Twitter hints that I should get my act together and finally
move
this to a
Hi,
On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote:
How about use INI until PHP8?
No. php.ini needs less settings not more. Especially not for language
things. This makes a mess for creating portable code. ze1 compat mode
was a fault as were other ini settings we had. Let's not go
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote:
Dear Internals,
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as their defining class will no
longer be recognized as constructors. As noted in the RFC, there are
Johannes Schlüter wrote on 21/11/2014 16:13:
Hi,
On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote:
How about use INI until PHP8?
No. php.ini needs less settings not more. Especially not for language
things. This makes a mess for creating portable code. ze1 compat mode
was a fault as
Nikita Popov wrote on 21/11/2014 16:22:
I'm also pretty confident that we can provide robust tooling for
automatically porting code to new constructors - including updating
parent:: call references if need be. Don't see how that would be a
particular issue here.
Given the contents of your
On Fri, Nov 21, 2014 at 1:07 AM, Zeev Suraski z...@zend.com wrote:
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
Given how long it has been since there was any activity on this topic,
I wish that you had issued a pre-vote
On Wed, Nov 19, 2014 at 07:17:48PM +0100, Julien Pauli wrote:
[Off Topic]
It's been a long time I've been thinking about having a compile-time
preprocessor integrated into our parser/compiler stack.
I would design it just to support #migration tokens, and nothing more.
This would really
On Fri, Nov 21, 2014 at 5:55 PM, Alain Williams a...@phcomp.co.uk wrote:
On Wed, Nov 19, 2014 at 07:17:48PM +0100, Julien Pauli wrote:
[Off Topic]
It's been a long time I've been thinking about having a compile-time
preprocessor integrated into our parser/compiler stack.
I would design it
On 21 November 2014 07:36, Ferenc Kovacs tyr...@gmail.com wrote:
In this case the 3 month period will be too short imo.
We release RCs/betas every two weeks, so 3 months would be about 6 release.
5.6.0 had 3 alpha, 4 beta and 4 rc before release.
5.5.0 had 6 alpha, 4 beta and 3 rc before
BTW, old constructor has problem with traits (is this mentioned already?)
http://3v4l.org/KZKXo
I suppose nobody is using this side effect in production code, but
there would be number of users who are confused by this behavior.
If I remember the source code correctly, this should be
Am 21.11.2014 um 02:53 schrieb Tjerk Meesters:
On 21 Nov 2014, at 02:14, Christoph Becker cmbecke...@gmx.de wrote:
Apparently, there is a somewhat hidden bug, see http://3v4l.org/El5Xs
for a simplified test script. The expected result is
string(14) ab,a\b
or maybe
string(14) a\b,a\\b
Thanks for your responses.
I saw pconn-sapi it's very similar threaded example that I want to
implement.
I've crated non blocking Event loop in my C++ application ( it's high load
binary API server ) , and now I'm trying to integrate PHP SAPI for writing
some customisable scripts using PHP
On Fri, 2014-11-21 at 23:06 +0400, Tigran Bayburtsyan wrote:
And based on that now my main problem is that in PHP C++ sources there
are a lot of static, global variables which is not useful for me, to
clean that all for every request So I'm wondering to build
something which will help
On Sat, Nov 22, 2014 at 2:18 AM, Zeev Suraski z...@zend.com wrote:
On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Nov 21, 2014 at 9:07 AM, Zeev Suraski z...@zend.com wrote:
After some Twitter hints that I should get my act together and finally move
this to a
hi,
This RFC is not about compete aganst Zeev's RFC but to get all issues
related to PHP 7 and a possible 5.7 release solved in one go.
Many here think that the timeline proposed (one year, less now) is not
realistic. It is not correct to simply ignore us and push yet again
another RFC, using
On Fri, Nov 21, 2014 at 7:10 AM, Zeev Suraski z...@zend.com wrote:
Kris,
This existed in the RFC since the get go and I don't believe anybody
raised any concerns about it. There was plenty of time for discussion.
Either way approval of this RFC won't have any effect on the approval or
-Original Message-
From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On
Behalf Of Levi Morrison
Sent: Friday, November 21, 2014 6:48 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline
The timeline for Line up any remaining RFCs
Ferenc, all,
The RFC has provisions for making the 3rd and 4th milestones move as needed:
“It's worth noting that the 3rd and 4th milestones will be quality
dependent. If we have evidence that suggests that PHP 7 isn't sufficiently
mature to go into the RC stage in June, or GA in October -
34 matches
Mail list logo
