[PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Zeev Suraski]

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

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Joe Watkins]

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 milestones column needs to change from mid October to
November.

Cheers
Joe


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

[Andrea Faulds]

> On 21 Nov 2014, at 03:02, Adam Harvey  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 how ext/standard (and pretty much all of PHP
> other than a smattering of OO functions and SPL) signal errors, and
> avoid duplication. I don't really fancy explaining the difference
> between to_* and try_* in ##php to a new developer.
> 
> PHP may be a mishmash of undesigned APIs in places, but that doesn't
> mean we should dump fuel on the fire by adding two parallel APIs that
> are named obscurely and differ only in how they signal errors.
> 
> There's no function in php-src today that throws an exception outside
> of an OO context. (Indeed, if you go through the various classes and
> methods in php-src, I suspect even _in_ an OO context the majority of
> errors are signalled via return values or PHP errors.)
> 
> Right now, the standard for appropriateness when adding an exception
> is pretty much "is this an error generated in an OO context"? This
> clearly isn't.
> 
> To be clear: if a way could be designed to do it without shredding BC,
> I'd be ecstatic if we deprecated our current error handling system
> entirely in favour of exceptions in PHP 7. But that's not the standard
> right now, and an unrelated RFC like this isn't the place to make that
> decision.
> 
> Why would you throw an E_RECOVERABLE_ERROR? The error's been
> signalled: the function returned NULL, rather than an
> int/float/string.

try_ serves a different use case to to_. to_ is mostly supposed to be a last 
line of defence. The only reason it's any safer than an explicit cast is that 
it throws an error that will halt execution if it goes unhandled. If you have 
to explicitly check for an error, that means people won't, and the aim of 
making safer casting as convenient as unsafe casting will not have been 
achieved. So, the alternative would be an E_RECOVERABLE_ERROR.

try_ exists so you can use the to_ functions in a validation context, where 
exceptions shouldn't be used for flow control. Of these two sets of functions, 
if I have to get rid of one, it'd be try_.

Also, a special note: to_/try_string is particularly useful if you want to 
gracefully handle casting of objects which lack __toString to a string, one of 
the only cases currently where an explicit cast can fail. There's currently no 
way to do this aside from checking for the existence of __toString, which isn't 
necessarily correct as an internal class can allow casting to string without 
defining that method.

--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Lester Caine]

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 version with the new constructors in place, and 
> the consumer of the library must then audit their code for anything relying 
> on the old constructor. Supporting various combinations of PHP 5/7, old/new 
> lib, and old/new consumer code is then messy at best.
> 
> I agree that it's perfectly doable, but it's not as easy to migrate as, say, 
> a syntax change.

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 that it will work on the
next release ... hiding things does not work.

And I still run my own version of PEAR to get around the e_strict problems!

-- 
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

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

[Lester Caine]

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
THAT process, the database will be validating data being passed to an
integer or float field as well, and may not follow the same 'new' rules.
There are a number of areas where this is just bloat which has to be
handled differently anyway. For PHP7 the whole picture needs to be
reviewed, not just yet more sticking plasters.

-- 
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

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins  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:
> >
> >
> >
> > https://wiki.php.net/rfc/php7timeline#vote
> >
> >
> >
> > Cast your vote!
> >
> >
> >
> > Zeev
>
> Morning Zeev,
>
> Proposed milestones column needs to change from mid October to
> November.
>
> Cheers
> Joe
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Looks good, except I think you should remove the language expressing
opinion about the general merits of backwards compatibility, as that falls
outside the scope of the timeline being voted on.  Plus it's an issue that
really should be discussed and, if needed, voted on separately, not as a
single sentence stuffed into an RFC about a release timeline.  If I were to
vote yes on this timeline, I would not want my vote interpreted as an
endorsement of that position on BC.  I think it's overreach and scope creep
that should be removed.

Other than that one serious (but easily fixable) flaw, I think it's great!

--Kris

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

Specifically, this is the sentence that just seems completely out of place:

"Arguably, while we should definitely take the opportunity to implement
compatibility-breaking changes in 7.0, we also shouldn't turn it into a
compatibility-breaking festival, as the more we break, the more likely it
is users would delay upgrades, stay with old, insecure versions - or even
consider other alternative options."

Mind you, I don't necessarily disagree with this opinion, but I don't think
it belongs in this RFC as people's votes to approve the timeline could
later be construed as endorsements of the BC philosophy you expressed, as
well.  That bothers me, probably enough to make me vote against this, so I
really hope you remove it.  I'd certainly have no objection to seeing that
expanded into its own RFC, though.  =)

--Kris


On Fri, Nov 21, 2014 at 2:12 AM, Kris Craig  wrote:

>
>
> On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins 
> 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:
>> >
>> >
>> >
>> > https://wiki.php.net/rfc/php7timeline#vote
>> >
>> >
>> >
>> > Cast your vote!
>> >
>> >
>> >
>> > Zeev
>>
>> Morning Zeev,
>>
>> Proposed milestones column needs to change from mid October to
>> November.
>>
>> Cheers
>> Joe
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Looks good, except I think you should remove the language expressing
> opinion about the general merits of backwards compatibility, as that falls
> outside the scope of the timeline being voted on.  Plus it's an issue that
> really should be discussed and, if needed, voted on separately, not as a
> single sentence stuffed into an RFC about a release timeline.  If I were to
> vote yes on this timeline, I would not want my vote interpreted as an
> endorsement of that position on BC.  I think it's overreach and scope creep
> that should be removed.
>
> Other than that one serious (but easily fixable) flaw, I think it's great!
>
> --Kris
>
>
>

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Ferenc Kovacs]

On Fri, Nov 21, 2014 at 9:07 AM, 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
>

Hi,

could you update the timeline to mention when do you want to start the
alpha and beta cycle?
for 5.6 the start of the alpha cycle indicated that we don't accept new
proposals, and the start of the beta cycle indicated that we won't accept
new features even if the RFC was already proposed or even accepted (but the
patch wasn't finished or merged in time).
you do mention the RC cycle as point 3, and my guess is that point 2, could
be the beta cycle because your definition ("Finalize implementation &
testing of new features") matches what we do with betas, but if that
assumption is correct, then your RFC is missing a target date for the start
of the alpha cycle, and that is important to know if we want to keep the
rule that there could be no new RFCs targetting PHP7 after that date.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Rowan Collins]

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 that it will work on the
next release ... hiding things does not work.

And I still run my own version of PEAR to get around the e_strict problems!


To reply with a broken record of my own: E_STRICT does not indicate code 
that will break in a future version. Hiding E_STRICT notices will have 
absolutely no detrimental effect on your code, now or in the future. It 
is up to you if you want to improve the code by following the hints, or 
ignore them because the code works fine.


So, no this is not at all similar to the "problem" of E_STRICT, because 
that problem is not real.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Lester Caine]

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 ensure that it will work on the
>> next release ... hiding things does not work.
>>
>> And I still run my own version of PEAR to get around the e_strict
>> problems!
> 
> To reply with a broken record of my own: E_STRICT does not indicate code
> that will break in a future version. Hiding E_STRICT notices will have
> absolutely no detrimental effect on your code, now or in the future. It
> is up to you if you want to improve the code by following the hints, or
> ignore them because the code works fine.
> 
> So, no this is not at all similar to the "problem" of E_STRICT, because
> that problem is not real.

So everything that currently requires e_strict disabled to allow it to
work will continue to work in PHP7? Including the parts that have now
been marked for removal since being deprecated since PHP5.3?

In practice ... NO the code does not work fine UNLESS you ensure that
all of the infrastructure is still using old versions of libraries. And
even then we still get white screen responses with changes of PHP
versions. My point is that on one hand people are COMPLAINING that code
such as PHP 4 Constructors is not being updated and then ALSO claiming
that we don't need to ... PLEASE can we have a level playing field to
code to!

-- 
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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Jan Schneider]

Zitat von Lester Caine :


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 ensure that it will work on the
next release ... hiding things does not work.

And I still run my own version of PEAR to get around the e_strict
problems!


To reply with a broken record of my own: E_STRICT does not indicate code
that will break in a future version. Hiding E_STRICT notices will have
absolutely no detrimental effect on your code, now or in the future. It
is up to you if you want to improve the code by following the hints, or
ignore them because the code works fine.

So, no this is not at all similar to the "problem" of E_STRICT, because
that problem is not real.


So everything that currently requires e_strict disabled to allow it to
work will continue to work in PHP7? Including the parts that have now
been marked for removal since being deprecated since PHP5.3?


You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED  
in an earlier minor PHP release, a feature/construct cannot be removed  
from PHP.



In practice ... NO the code does not work fine UNLESS you ensure that
all of the infrastructure is still using old versions of libraries. And
even then we still get white screen responses with changes of PHP
versions. My point is that on one hand people are COMPLAINING that code
such as PHP 4 Constructors is not being updated and then ALSO claiming
that we don't need to ... PLEASE can we have a level playing field to
code to!


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.


--
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Matteo Beccati]

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 if there's a good reason, but this one seems a 
little weak. For reference 1/3 of the 4500+ php files in the project I 
work on every day still uses PHP4 constructors. And one third of them is 
within the bundled PEAR libraries.


I'm not saying it is quality code, but it's a dinosaur open source 
project... I believe that many other historical open source projects are 
in the same boat. All the (unpaid) time that the team(s) would need to 
waste on this could be better spent elsewhere.



Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Lester Caine]

On 21/11/14 12:36, Jan Schneider wrote:
> 
> Zitat von Lester Caine :
> 
>> 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 ensure that it will work on the
 next release ... hiding things does not work.

 And I still run my own version of PEAR to get around the e_strict
 problems!
>>>
>>> To reply with a broken record of my own: E_STRICT does not indicate code
>>> that will break in a future version. Hiding E_STRICT notices will have
>>> absolutely no detrimental effect on your code, now or in the future. It
>>> is up to you if you want to improve the code by following the hints, or
>>> ignore them because the code works fine.
>>>
>>> So, no this is not at all similar to the "problem" of E_STRICT, because
>>> that problem is not real.
>>
>> So everything that currently requires e_strict disabled to allow it to
>> work will continue to work in PHP7? Including the parts that have now
>> been marked for removal since being deprecated since PHP5.3?
> 
> You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED in
> an earlier minor PHP release, a feature/construct cannot be removed from
> PHP.

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 creates problems when other
actions change the goal posts yet again.

>> In practice ... NO the code does not work fine UNLESS you ensure that
>> all of the infrastructure is still using old versions of libraries. And
>> even then we still get white screen responses with changes of PHP
>> versions. My point is that on one hand people are COMPLAINING that code
>> such as PHP 4 Constructors is not being updated and then ALSO claiming
>> that we don't need to ... PLEASE can we have a level playing field to
>> code to!
> 
> 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.

It's following through on that with the rest of the infrastructure which
is the important thing. Once something is deprecated again simply hiding
the error is not going to get legacy code up to date so it then fails
when the target is actually removed.

Perhaps what I AM asking, is just that we need a clean roadmap for PHP7
on just what will be retained. Some of that may well need a PHP5.7 to
deprecate it and I'm not against this particular tidy up, but it does
need to be planned in the right way.

-- 
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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Rowan Collins]

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 creates problems when other
actions change the goal posts yet again.


So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED 
(less safe to hide). At that point, you can deal with the E_DEPRECATED 
notices *and carry on ignoring E_STRICT*.


Unless you can name an example of something which went from E_STRICT to 
fatal error? If so, that specific case was a violation of process, and 
should be highlighted.



The confusion is created by having two incompatible styles of coding


I asked this before, and you didn't answer: can you name something 
which, when you fix the E_STRICT notice, makes your code incompatible 
with something else? Or something which, if you *ignore* an E_STRICT 
notice, refuses to work?


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Lester Caine]

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'
>> code in to line with current practices it creates problems when other
>> actions change the goal posts yet again.
> 
> So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED
> (less safe to hide). At that point, you can deal with the E_DEPRECATED
> notices *and carry on ignoring E_STRICT*.
> 
> Unless you can name an example of something which went from E_STRICT to
> fatal error? If so, that specific case was a violation of process, and
> should be highlighted.

IF one is working through code to fix the deprecated warnings why would
one not fix the remaining e_strict. In may cases they are all in the
same area of the code base? That is the whole point here ... we can't
assume that the code will continue to work in the future.

>> The confusion is created by having two incompatible styles of coding
> 
> I asked this before, and you didn't answer: can you name something
> which, when you fix the E_STRICT notice, makes your code incompatible
> with something else? Or something which, if you *ignore* an E_STRICT
> notice, refuses to work?

TODAY things are a little tidier, and problems that were created over
many upgrades and a lot of the problems have been fixed but it's the
agro caused when third party libraries re-enabling e_strict, hosting
changing settings for other reasons and problems like that. All cause
problems which will only be cleared when all of the legacy code is
updated ... which means making them e_strict compliant ... which IS
under-way, but slow going.

I have had many situations where having upgraded one library so it's
then e_strict clean it has problems when used with it switched off. In
my book, code runs clean, if it creates warnings/errors then it needs
fixing, and so simply hiding these is what is not acceptable.

-- 
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

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Zeev Suraski]

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 paralyzing 39.5C temperature.  
Let's focus on what matters.  I at least don't have energy to respond to the 
rest.

Zeev

> On 21 בנוב׳ 2014, at 12:16, Kris Craig  wrote:
> 
> Specifically, this is the sentence that just seems completely out of place:
> 
> "Arguably, while we should definitely take the opportunity to implement 
> compatibility-breaking changes in 7.0, we also shouldn't turn it into a 
> compatibility-breaking festival, as the more we break, the more likely it is 
> users would delay upgrades, stay with old, insecure versions - or even 
> consider other alternative options."
> 
> Mind you, I don't necessarily disagree with this opinion, but I don't think 
> it belongs in this RFC as people's votes to approve the timeline could later 
> be construed as endorsements of the BC philosophy you expressed, as well.  
> That bothers me, probably enough to make me vote against this, so I really 
> hope you remove it.  I'd certainly have no objection to seeing that expanded 
> into its own RFC, though.  =)
> 
> --Kris
> 
> 
>> On Fri, Nov 21, 2014 at 2:12 AM, Kris Craig  wrote:
>> 
>> 
>>> On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins  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:
>>> >
>>> >
>>> >
>>> > https://wiki.php.net/rfc/php7timeline#vote
>>> >
>>> >
>>> >
>>> > Cast your vote!
>>> >
>>> >
>>> >
>>> > Zeev
>>> 
>>> Morning Zeev,
>>> 
>>> Proposed milestones column needs to change from mid October to
>>> November.
>>> 
>>> Cheers
>>> Joe
>>> 
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> Looks good, except I think you should remove the language expressing opinion 
>> about the general merits of backwards compatibility, as that falls outside 
>> the scope of the timeline being voted on.  Plus it's an issue that really 
>> should be discussed and, if needed, voted on separately, not as a single 
>> sentence stuffed into an RFC about a release timeline.  If I were to vote 
>> yes on this timeline, I would not want my vote interpreted as an endorsement 
>> of that position on BC.  I think it's overreach and scope creep that should 
>> be removed.
>> 
>> Other than that one serious (but easily fixable) flaw, I think it's great!
>> 
>> --Kris
> 

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Zeev Suraski]

> On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs  wrote:
> 
> 
> 
>> On Fri, Nov 21, 2014 at 9:07 AM, 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
> 
> Hi,
> 
> could you update the timeline to mention when do you want to start the alpha 
> and beta cycle?

> for 5.6 the start of the alpha cycle indicated that we don't accept new 
> proposals, and the start of the beta cycle indicated that we won't accept new 
> features even if the RFC was already proposed or even accepted (but the patch 
> wasn't finished or merged in time).
> you do mention the RC cycle as point 3, and my guess is that point 2, could 
> be the beta cycle because your definition ("Finalize implementation & testing 
> of new features") matches what we do with betas, but if that assumption is 
> correct, then your RFC is missing a target date for the start of the alpha 
> cycle, and that is important to know if we want to keep the rule that there 
> could be no new RFCs targetting PHP7 after that date.

I think the "finalize implementation" stage corresponds to our alpha stage, as 
we're not feature complete.

The proposal does suggest to go directly to an RC cycle afterwards, but it 
could read beta / RC too.  The difference between betas and RCs is typically 
very small, they're both feature complete and only imply different levels of 
quality.  Personally I don't think we need both.

Zeev

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Ferenc Kovacs]

On Fri, Nov 21, 2014 at 4:18 PM, Zeev Suraski  wrote:

>
> On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs  wrote:
>
>
>
> On Fri, Nov 21, 2014 at 9:07 AM, 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
>>
>
> Hi,
>
> could you update the timeline to mention when do you want to start the
> alpha and beta cycle?
>
>
> for 5.6 the start of the alpha cycle indicated that we don't accept new
> proposals, and the start of the beta cycle indicated that we won't accept
> new features even if the RFC was already proposed or even accepted (but the
> patch wasn't finished or merged in time).
> you do mention the RC cycle as point 3, and my guess is that point 2,
> could be the beta cycle because your definition ("Finalize implementation &
> testing of new features") matches what we do with betas, but if that
> assumption is correct, then your RFC is missing a target date for the start
> of the alpha cycle, and that is important to know if we want to keep the
> rule that there could be no new RFCs targetting PHP7 after that date.
>
>
> I think the "finalize implementation" stage corresponds to our alpha
> stage, as we're not feature complete.
>

ok


>
> The proposal does suggest to go directly to an RC cycle afterwards, but it
> could read beta / RC too.  The difference between betas and RCs is
> typically very small, they're both feature complete and only imply
> different levels of quality.  Personally I don't think we need both.
>

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 release.
5.4.0 had 3 alpha, 2 beta and 8 rc before release.
5.3.0 had 3 alpha, 1 beta and 4 rc before release
5.2.0 had 6 rc before release.
5.1.0 had 6 rc before release.

based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.

sorry if this seems to be nitpicking, just trying to put my experiences
into use.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Johannes Schlüter]

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 there,
again.


johannes




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Nikita Popov]

On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison  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
> already many situations where we do not recognize these methods as
> constructors, such as in namespaces and traits and when `function
> __construct` is also present.
>
> Andrea Faulds has kindly written a utility that identifies when a PHP
> 4 constructor is defined[2]. It does not automatically change the code
> for liability reasons. The utility PHPMD[3] can also detect this but
> has a false positive when `__construct` is also defined.
>
> Cheers,
> Levi Morrison
>

I'm +1 on this RFC.

I've lost count of the number of times I had to debug some "completely
impossible" behavior I got while writing quick testing code (which is
obviously not namespaced), because I accidentally created a class "Test"
with a method "test" or similar.

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.

Nikita

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Rowan Collins]

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 were other ini settings we had. Let's not go there,
again.


I agree; the runtime environment is not the right scope to set such options.

I do wonder if it would be useful to make more use of declare() though, 
which is scoped to a single file, and could be used like Perl's Pragmas.


Annoyingly, unrecognised declare() options issue a warning, so you can't 
rely on older versions silently ignoring a new flag such as 
declare(compat_flags=php4_constructors); http://3v4l.org/cikUU


Apparently, @ can't be used to suppress the warning, either, since the 
parser chokes (I guess because declare() isn't really a statement as 
such): http://3v4l.org/DFBfO


I'm not sure it would actually make sense for this case, anyway, but 
some global behaviours would definitely benefit from being scoped this 
way e.g. suppress notices in deprecated / 3rd-party code, but show them 
in your own new modules, or ensure strlen is not over-ridden by mbstring 
in a library which needs to count bytes.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Rowan Collins]

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 github repo, I'm inclined to take your word 
for it on that! :)



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Levi Morrison]

On Fri, Nov 21, 2014 at 1:07 AM, 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:

Given how long it has been since there was any activity on this topic,
I wish that you had issued a pre-vote email to the list to solicit
more feedback. Oh well.

I think working towards an October/November 2015 release is good; I
just want to clarify one thing:

The timeline for "Line up any remaining RFCs that target PHP 7.0."
ends on March 15, 2015. This implies that feature freeze will happen
on that date, correct?

This is an important thing to recognize if I am correct, as it is only
four months away.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [OFFTOPIC] conditional compilation, WAS [RFC] Remove PHP 4 Constructors

[Alain Williams]

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 ease migrations, with no runtime impact at all, and
> the possibility to use any syntax, knowing it will get compiled, which
> is not possible nowadays.
> Like the C preprocessor. And it wouldn't be that hard to add to our
> codebase, as there should not be any runtime impact, just a two-pass
> parser
> 
> Anyone interested can contact me :-)
> 
> [/Off Topic]

If you do, then please back port it to at least PHP 5.3 If you did then we would
be able to write code with new syntaxes (that won't compile under 5.3/whatever)
and automatically use them when the code is run under whatever version supports
the syntax.

Going back to the example that I gave & thinking a bit, a '$#' at the start of
line (not recognised anywhere else) would work. It is an error under different
circumstances and is sufficiently reminicent of C to be helpful of those of us
with that background.

$# if PHP_VERSION_ID > 50500
$# else
$# endif

Without wanting to make it too complicated, it might be nice to allow a 'set'
(or 'define'), this would allow setting of flags, eg:

$# if PHP_VERSION_ID > 50500
$# set FINALLY 1
$# endif

$# if FINALLY
 ...
$#endif

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [OFFTOPIC] conditional compilation, WAS [RFC] Remove PHP 4 Constructors

[Julien Pauli]

On Fri, Nov 21, 2014 at 5:55 PM, Alain Williams  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 just to support #migration tokens, and nothing more.
>> This would really ease migrations, with no runtime impact at all, and
>> the possibility to use any syntax, knowing it will get compiled, which
>> is not possible nowadays.
>> Like the C preprocessor. And it wouldn't be that hard to add to our
>> codebase, as there should not be any runtime impact, just a two-pass
>> parser
>>
>> Anyone interested can contact me :-)
>>
>> [/Off Topic]
>
> If you do, then please back port it to at least PHP 5.3 If you did then we 
> would
> be able to write code with new syntaxes (that won't compile under 
> 5.3/whatever)
> and automatically use them when the code is run under whatever version 
> supports
> the syntax.
>
> Going back to the example that I gave & thinking a bit, a '$#' at the start of
> line (not recognised anywhere else) would work. It is an error under different
> circumstances and is sufficiently reminicent of C to be helpful of those of us
> with that background.
>
> $# if PHP_VERSION_ID > 50500
> $# else
> $# endif
>
> Without wanting to make it too complicated, it might be nice to allow a 'set'
> (or 'define'), this would allow setting of flags, eg:
>
> $# if PHP_VERSION_ID > 50500
> $# set FINALLY 1
> $# endif
>
> $# if FINALLY
>  ...
> $#endif
>
> --


Hello,

We are (because I'm not alone anymore having this idea and already got
private feedback) working on something much more simple, based on the
declare() structure.

The idea is to have something that could make PHP compile only syntax
it knows, and not older syntax (prevent parse errors or use a better
implementation).

Obviously, this will not be pushed to stable branches, and could
target PHP7 if we decide to push it to an RFC.

declare(php_version >= 5.6) {
   function foo($a, ...$b) { }
}

Very first ideas, need more reflection, then an RFC draft

Julien.P

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Adam Harvey]

On 21 November 2014 07:36, Ferenc Kovacs  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 release.
> 5.4.0 had 3 alpha, 2 beta and 8 rc before release.
> 5.3.0 had 3 alpha, 1 beta and 4 rc before release
> 5.2.0 had 6 rc before release.
> 5.1.0 had 6 rc before release.
>
> based on that I would say that our average beta+rc release number is around
> 7, and sometimes the release for a beta/RC can be delayed, so I think that
> having only 3 months for the beta+RC period is too optimistic, we should
> make that into 4 months at least, we could either push out the ETA for GA
> or move back the alpha period by a month.

Agreed. This is the key reason why our "annual" release cycle has been
"15 monthly" in practice — we've consistently underestimated the
number of beta and RC releases required for a .0 stable.

Adam

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Levi Morrison]

> 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 considered a
bug. I will definitely look into this, regardless of the outcome of
this RFC.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: fgetcsv incompatible with fputcsv

[Christoph Becker]

Am 21.11.2014 um 02:53 schrieb Tjerk Meesters:

>> On 21 Nov 2014, at 02:14, Christoph Becker  wrote:
>>
>> Apparently, there is a somewhat hidden bug, see 
>> for a simplified test script.  The expected result is
>>
>>  string(14) ""a""b","a\""b""
>>
>> or maybe
>>
>>  string(14) ""a\"b","a\\"b""
>>
>> The actual result makes no sense to me, even though str_getcsv() parses
>> it "correctly”.
> 
> That works exactly for the wrong reasons:
> 1) upon seeing an escape character fgetcsv() will print that and the 
> following character
> 2) fputcsv() actually accepts an escape character too (despite what the 
> documentation says) but treats it in the wrong way by not escaping that and 
> the following character

Ah, I see, thanks for the explanation.  Apparently[1], the $escape
parameter to fputcsv() has been added in PHP 5.5.  I have made a
respective edit at edit.php.net.

BTW: wouldn't it be reasonable to also add the $escape parameter to
SplFileObject::fputcsv()?  For now one has to use
SplFileObject::setCsvControl().

> The expected output, based on the given code should (imo) be:
> 
> string(15) ""a\"b","a\\\"b""
> 
> Or: if the escape character is a double quote:
> 
> string(15) “"a""b",”a\""b””

ACK.  (Even though that would be a BC break.)

> Unfortunately I can’t satisfy all the related bug reports, some decision of 
> “correctness” needs to be made in the form of an RFC.

ACK.  Thanks for taking the time. :)

[1]  vs


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP SAPI module help

[Tigran Bayburtsyan]

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 functions.
My app starting PHP SAPI  with function php_embed_init(argc, argv PTSRMLS_CC);
 and it stays alive always , because it will take some preference from my
app if I'll start and end PHP SAPI on every PHP script parsing or function
call.
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 to somehow "save current state" of PHP SAPI , and continue it on every
request from saved source, without sharing any variable between multiple
requests.

Let me know if you didn't get my idea.
Now I'm trying to do this thing for my Startup project, but I'll share it
over GitHub if I'll have some success :)

Thanks.


2014-11-20 15:34 GMT+04:00 Johannes Schlüter :

> On Thu, 2014-11-20 at 19:19 +0800, 兰 肖鲁 wrote:
> > How about writing this logic in an extension?  Because u can write
> > your own RSHUTDOWN function to protect your data.
>
> Sorry, I have no idea what logic you want to put in a rshutdown and what
> data you want to protect. And how that relates to this discussion around
> SAPIs.
>
> johannes
>
>
>

Re: [PHP-DEV] PHP SAPI module help

[Johannes Schlüter]

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 to somehow "save current state" of PHP
> SAPI , and continue it on every request from saved source, without
> sharing any variable between multiple requests.

If you need to cleanup things between requests php_request_[startup|
shutdown] are the functions you need which will do that.

Basic flow in pseudocode with reference to pconn functions doing a bit
more:

  /* once on application start, see also pconn_init_php() */
  sapi_startup();
  
  /* for each request, see pconn_do_request() */
  while (!program_end()) {
/* start request context */
php_request_startup(TSRMLS_C);

/* we can multiple scripts in one request context */
while (get_script_for_current_request()) {
if (source_is_in_a_file()) {
php_execute_script(file_handle TSRMLS_CC);
} else if (source_is_in_a_string()) {
zend_eval_String();
}
}

/* clean up everything related to the request */
php_request_shutdown((void *) 0);
  }
  
  /* at the end of the application shutdown completely */
  php_module_shutdown(TSRMLS_C);
  sapi_shutdown();

Now this uses global state. If you need multiple states parallel compile
PHP in threaded mode (--enable-maintainer-zts manually at config time or
force it by PHP_BUILD_THREAD_SAFE in your SAPI's custom config.m4. In
that mode PHP globals which are request-specific (i.e. everything that
happens in the while (!program_end()) loop) are bound to a windows
thread or pthread (depending on platform). So if your event based system
needs multiple PHP requests in parallel it has to create enough threads
and route PHP work there. Handling multiple requests from a single
thread in parallel is not supported from PHP's architecture (if you like
adventures you might try to hack this by looking at tsrm_thread_id in
TSRM/TSRM.c but that's not really a good way.

Another approach is not embedding PHP directly in your process (which is
dangerous anyways - PHP might crash due to stack overflow on some
recursion patterns etc. which would kill your complete server) but by
calling external PHP processes via FastCGI or FPM protocols, just like
nginx or others do.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Pierre Joye]

On Sat, Nov 22, 2014 at 2:18 AM, Zeev Suraski  wrote:
>
>> On 21 בנוב׳ 2014, at 13:06, Ferenc Kovacs  wrote:
>>
>>
>>
>>> On Fri, Nov 21, 2014 at 9:07 AM, 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
>>
>> Hi,
>>
>> could you update the timeline to mention when do you want to start the alpha 
>> and beta cycle?
>
>> for 5.6 the start of the alpha cycle indicated that we don't accept new 
>> proposals, and the start of the beta cycle indicated that we won't accept 
>> new features even if the RFC was already proposed or even accepted (but the 
>> patch wasn't finished or merged in time).
>> you do mention the RC cycle as point 3, and my guess is that point 2, could 
>> be the beta cycle because your definition ("Finalize implementation & 
>> testing of new features") matches what we do with betas, but if that 
>> assumption is correct, then your RFC is missing a target date for the start 
>> of the alpha cycle, and that is important to know if we want to keep the 
>> rule that there could be no new RFCs targetting PHP7 after that date.
>
> I think the "finalize implementation" stage corresponds to our alpha stage, 
> as we're not feature complete.
>
> The proposal does suggest to go directly to an RC cycle afterwards, but it 
> could read beta / RC too.  The difference between betas and RCs is typically 
> very small, they're both feature complete and only imply different levels of 
> quality.  Personally I don't think we need both.

This is not the case. Beta means beta status but may be not features
complete (as patch may have not made it yet). RCs on the other hand
are. RC means no more addition and focus only on fixing things.

This RFC is incomplete and unrealistic, besides not taking into
account other opinions. It should go back to discussions and solve the
obvious issues before even thinking about voting on it.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Alternative RFC for 7 roadmap and 5.7

[Pierre Joye]

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 the benefits brought by 7 as a motor.

I have tried since weeks to get Zeev to add his view to this RFC,
discussed with Andi about it (who confirmed that Zeev will do it), but
the result was slightly different to what we were expecting. That's
why I go now with that one while being fair and correct by including
Zeev's RFC in there as well. Zeev, please update it accordingly if you
made any change to your original proposal.


It also includes the vote about 5.7 and the aims about having a 5.7 release.

Please keep in mind that all dates in there are about a maximum
release time. If we are ready before, let release it. But I am
convinced that we need slightly more time to discuss some new features
as well as the stabilization of the engine will need more time than
defined in Zeev's proposal.

Let sort all these issues in the proposals (RMs can tell their
experiences and issues, so we can take them into accounts too) and get
back to code :)

https://wiki.php.net/rfc/php7_57_roadmap

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

On Fri, Nov 21, 2014 at 7:10 AM, Zeev Suraski  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
> rejection of other RFCs.
>

I have to agree with the concerns raised by Levi and Pierre regarding this
matter.  Regardless of the reasons, too much time has passed since those
discussions for them to really be relevant today, and it does feel a bit
sudden to have this suddenly pop-out for a vote after all this time and
without any warning.

As far as the issue I raised is concerned, didn't I raise that same concern
during the last discussion?  I could be mistaken, but now that you mention
it, I don't think this is the first time I've raised concerns about that.

Besides, the whole "I can't focus on that because it's not important"
argument just doesn't make any sense to me.  It adds nothing to the RFC and
would literally take like 5 seconds to remove; probably about the same time
it took for you to explain in that email why it wasn't worth removing.  In
any case, I am definitely raising concern about it now and I'm not aware of
any rule saying that's not permitted.  If you like, I'll even fix it for
you with your permission (since it's literally just removing a single
sentence) so you don't have to waste any time/energy dealing with it.


> Kris, All - I'm now on a 7th day straight of a paralyzing 39.5C
> temperature.  Let's focus on what matters.  I at least don't have energy to
> respond to the rest.
>

Holy shit that sucks!  I can certainly understand your lack of patience in
dealing with issues surrounding this RFC.  Unfortunately, they are
important-- at least, they're important to the people who are raising
them.  It may be prudent for you to find someone you trust to help you
address them given your situation.  Either way, this abrupt vote after such
a long pause does concern me, as does the apparent lack of willingness to
discuss concerns with it.  These are just my opinions, of course, but for
whatever it's worth, I have some serious concerns about this.

--Kris

RE: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Zeev Suraski]

> -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 that target PHP 7.0."
> ends on March 15, 2015. This implies that feature freeze will happen on
> that
> date, correct?

This is 'feature definition freeze'.  It's not the standard 'feature freeze'
as it's defined in the industry, which means we're done *developing* the
features.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Zeev Suraski]

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 - we should of
course adjust the timeline accordingly, and not push out a half-baked
release. However, the goal would be to stick as much as possible to the
deadline of new going-into-7.0 RFCs, and strive to follow the timelines for
the 2nd and 3rd milestones as much as possible, to ensure an October 2015
release of PHP 7.0.”



This language attempts to balance the motivation to get PHP 7.0 out to
market as soon as possible, with the unwillingness to compromise on
quality.  If we end up having to have 4 months of betas/RCs instead of 3 –
then we will…



Zeev





based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.



sorry if this seems to be nitpicking, just trying to put my experiences
into use.



-- 

Ferenc Kovács
@Tyr43l - http://tyrael.hu