Re: [PHP-DEV] 7.0 Release Management

On Sun, Mar 22, 2015 at 3:38 AM, Leigh wrote: > Hi all, > > With 7.0 feature freeze in effect, and proposals and RFCs still coming in > that are going to target 7.1, I think it's time we branched master and > selected a release manager (or two) for 7.0. > I would branch only in time for the firs

Re: [PHP-DEV] 7.0 Release Management

Hi Leigh 2015-03-22 2:38 GMT+01:00 Leigh : > Hi all, > > With 7.0 feature freeze in effect, and proposals and RFCs still coming in > that are going to target 7.1, I think it's time we branched master and > selected a release manager (or two) for 7.0. I expressed sometime last year after we named

[PHP-DEV] 7.0 Release Management

Hi all, With 7.0 feature freeze in effect, and proposals and RFCs still coming in that are going to target 7.1, I think it's time we branched master and selected a release manager (or two) for 7.0. Traditionally the newer RM from the previous release stays on, and a new RM is introduced who will

Re: [PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

On 21 March 2015 at 12:30, Peter Cowburn wrote: > On 21 March 2015 at 08:14, Xinchen Hui wrote: > > > Hey: > > > > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote: > > > Hey: > > > > > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams > > wrote: > > >> On Fri, Mar 20, 2015 at 10:46:58PM +11

Re: [PHP-DEV] Proposal to delay 7.0 timeline

Please do not delay. Any one remember PHP 6 ? Delay is bad smell. means the project will failure. PHP 7 already had much more features. That's fine . Just ship it . Appreciate your time. Netroby 2015-03-22 4:09 GMT+08:00 Benoit Schildknecht : > Le Sat, 21 Mar 2015

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

Hi, 2015-03-21 19:30 GMT+01:00 Marc Bennewitz : > I also had a question! Didn't you noticed it? > > Am 20.03.2015 um 16:49 schrieb Marc Bennewitz: >> >> Why not simply allow the callback to be an array, too? Because arrays are valid callbacks. [$object, 'cb'] would call the the 'cb' method on the

Re: [PHP-DEV] WIKI Account Request

On Sat, Mar 21, 2015 at 6:13 PM, Christoph Becker wrote: > Ferenc Kovacs wrote: > > > I can't find your account request, are you sure you was able to submit > it? > > The form won't be submitted if you fill out the ' To which email address > do > > you have to send an email now?' question wrong.

Re: [PHP-DEV] Proposal to delay 7.0 timeline

Le Sat, 21 Mar 2015 18:44:23 +0100, Pierre Joye a écrit: On Mar 21, 2015 11:55 PM, "Zeev Suraski" wrote: Sent from my mobile > On 21 במרץ 2015, at 18:05, Rasmus Lerdorf wrote: > >> On 03/21/2015 08:52 AM, François Laupretre wrote: >> Now, after more calls from many of you to delay it,

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

I also had a question! Didn't you noticed it? Am 20.03.2015 um 16:49 schrieb Marc Bennewitz: Why not simply allow the callback to be an array, too? Marc Am 21.03.2015 um 09:14 schrieb Xinchen Hui: Hey: On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote: Hey: On Fri, Mar 20, 2015 at 7:53

[PHP-DEV] Fwd: Need authorization as New Wiki User

*Hello,* I am Shaharia, recently created PHP Wiki account with this email address. My username was *'shaharia'. * As a PHP programmer since 7.5 years I always love to contribute to any kinds of open source project. And PHP is my passion and using it since long time and managing my app development

Re: [PHP-DEV] RFC: Nested enclosing returns

To be honest I had not thought about the bad side of this use, i guess it could be possible to not return upper than a try/catch block (then return a fatal error if our code is trying to returns upper than a try/catch block). Now the practical example: // Code i have the hand on function main() {

Re: [PHP-DEV] Proposal to delay 7.0 timeline

On Mar 21, 2015 11:55 PM, "Zeev Suraski" wrote: > > > > Sent from my mobile > > > On 21 במרץ 2015, at 18:05, Rasmus Lerdorf wrote: > > > >> On 03/21/2015 08:52 AM, François Laupretre wrote: > >> Now, after more calls from many of you to delay it, and as Zeev himself > >> seemed to consider it as

[PHP-DEV] Re: VCS Account Request: tgdice

VCS Account Rejected: tgdice rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] WIKI Account Request

Ferenc Kovacs wrote: > I can't find your account request, are you sure you was able to submit it? > The form won't be submitted if you fill out the ' To which email address do > you have to send an email now?' question wrong. There should be a meaningful error message now (since a few days), if s

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann: It was my idea, after all, only fair that I invest the time to make it into an RFC: https://wiki.php.net/rfc/throwable The vote for this missed the boat for the PHP 7 deadline. However, if we really want to do this we should do it in PHP 7 or

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Am 15.03.2015 um 09:24 schrieb Pavel Kouřil: why global namespace? Because that is where, as of today, built-in classes, interfaces, functions, etc. go. The introduction of a PHP namespace, for instance, would be the topic of a separate RFC. -- PHP Internals - PHP Runtime Development Mai

Re: [PHP-DEV] Proposal to delay 7.0 timeline

Sent from my mobile > On 21 במרץ 2015, at 18:05, Rasmus Lerdorf wrote: > >> On 03/21/2015 08:52 AM, François Laupretre wrote: >> Now, after more calls from many of you to delay it, and as Zeev himself >> seemed to consider it as more acceptable, I am proposing again to delay 7.0 >> feature fre

[PHP-DEV] Re: VCS Account Request: ivangabriele

VCS Account Rejected: ivangabriele rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: dustin

VCS Account Rejected: dustin rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Nested enclosing returns

On Mar 21, 2015, at 10:17, Georges.L wrote: > The main purpose of this RFC is *not* to improve the exception system of > PHP but to improve the code logic/hierarchy. > >>> Hi php internals, >>> >>> After some long and deep research i finally decided to write my first RFC >>> about a feature i'

Re: [PHP-DEV] Proposal to delay 7.0 timeline

On 03/21/2015 08:52 AM, François Laupretre wrote: > Now, after more calls from many of you to delay it, and as Zeev himself > seemed to consider it as more acceptable, I am proposing again to delay 7.0 > feature freeze to May, 15 (2 month delay, date where vote is starting). I > won’t repeat all th

[PHP-DEV] Proposal to delay 7.0 timeline

Hi, One month ago, I sent a message (https://marc.info/?l=php-internals &m=142449701107797) explaining in details why I thought we should take more time to gather features for 7.0. Zeev replied that it was absolutely impossible, and that th

Re: [PHP-DEV] WIKI Account Request

On Thu, Mar 19, 2015 at 3:35 PM, Mike Willbanks wrote: > Hello Internals, > > I had requested a wiki account (mwillbanks) as I would like to propose an > RFC on Object casts to scalar types. This has previously been discussed > prior to scalar type hints and since we have those now coming into P

Re: [PHP-DEV] RFC: Nested enclosing returns

The main purpose of this RFC is *not* to improve the exception system of PHP but to improve the code logic/hierarchy. Using this like loop (for/foreach etc.) you can skip a lot of parent callers for a desired purpose by example. I agree with you in the sens were this can complicate significantly

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

> > I think that, while attractive, using the same syntax for object methods > and scalar 'pseudo-'methods is too ambiguous. We just need to solve two > issues : intuitive order of arguments and nested call readability. We don't > need to implement the whole OO stuff for scalars. Except this detail

Re: [PHP-DEV] RFC: Nested enclosing returns

On Sat, Mar 21, 2015 at 1:13 PM, Georges.L wrote: > Hi php internals, > > After some long and deep research i finally decided to write my first RFC > about a feature i'd be interested to be improved in the php core: *Nested > enclosing returns* > > > The main purpose, as the title say, is to have

[PHP-DEV] RFC: Nested enclosing returns

Hi php internals, After some long and deep research i finally decided to write my first RFC about a feature i'd be interested to be improved in the php core: *Nested enclosing returns* The main purpose, as the title say, is to have the possibility to nest multiple return like we can do currently

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

This shouldn't be for PHP 7.0 ofcourse it's too late. it takes a lot of work and we don't want to get it wrong the second time :) but in any release before PHP 8 On Sat, Mar 21, 2015 at 10:25 AM, Pierre Joye wrote: > > On Mar 21, 2015 2:15 PM, "Levi Morrison" wrote: > > > > > I know that many

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

Hey Internals, > I'd like to put the variadic empty() RFC to vote. > > RFC: https://wiki.php.net/rfc/variadic_empty > > Voting will finish in 14 days time on March 21st. Voting has now ended with a 26:26 yes/no split. This means the RFC has has been declined (namely surrounding the ambiguity of w

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

How you don't think this is so important ? i stated this because it's so predictable that someone will say it. Firstly why it's "fake" ? i prefer "elegant" maybe not the PERFECT solution ? i suggest that you compare the two choices. and what would you chose if you're a new comer. Secondly this is

RE: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

> De : Nathan wesley [mailto:nathan.o.wes...@gmail.com] > > The old API should be deprecated in PHP 8.0 and removed completely in PHP > 9.0 (finally) That's totally unrealistic. The old API will remain forever (well, we'll examine the case again in 20 years...). I had planned to propose somethi

[PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

On 21 March 2015 at 08:14, Xinchen Hui wrote: > Hey: > > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote: > > Hey: > > > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams > wrote: > >> On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote: > >>> On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Would it make more sense then to have a RFC for array by positional index. No range or anything initially (that will be a separate RFC), but simply to get the value of an array by positional index? $array[*4] to get the item in position 4.

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

On 21/03/15 04:01, Nathan wesley wrote: > The old API should be deprecated in PHP 8.0 and removed completely in PHP > 9.0 (finally) WHY? You don't HAVE to use the current API and wiping out all of the legacy code does not seem like a 'gain'. The two can co exist. > I hope that you take this serio

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

2015-03-21 8:25 GMT+01:00 Pierre Joye : > On Mar 21, 2015 2:15 PM, "Levi Morrison" wrote: > > > > > I know that many people here will say that it’s not that important > > > developers get used to this API and many tutorials based on it. > > > > As you guessed, I don't think this is so important t

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

Hey: On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote: > Hey: > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams wrote: >> On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote: >>> On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai wrote: >>> > Hi internals, >>> >> Hi internals, >>> >> >>> >> T

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

On Mar 21, 2015 2:15 PM, "Levi Morrison" wrote: > > > I know that many people here will say that it’s not that important > > developers get used to this API and many tutorials based on it. > > As you guessed, I don't think this is so important that we should > create a new "fake" object syntax for

Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

> I know that many people here will say that it’s not that important > developers get used to this API and many tutorials based on it. As you guessed, I don't think this is so important that we should create a new "fake" object syntax for scalar. That's shooting a mouse with an elephant gun. -- P