Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71905
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain yamiko.org does not designate 74.124.212.71 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 31 Jan 2014 15:09:31 -0800
To: internals@lists.php.net
Organization: Yamiko LLC
In-Reply-To: <BF.14.54292.9A62CE25@pb1.pair.com>
References: <98.E0.35265.E17FBE25@pb1.pair.com>
 <1391203805.2941.173.camel@guybrush> <BF.14.54292.9A62CE25@pb1.pair.com>
Message-ID: <5074343e6a283e2a0f47284ac7b49d16@yamiko.org>
User-Agent: Roundcube Webmail/0.9.5
Subject: Re: [PHP-DEV] [VOTE] Automatic Property Initialization
From: rparker@yamiko.org (Robert Parker)

On 2014-01-31 14:41, Pascal Chevrel wrote:
> Le 31/01/2014 22:30, Johannes Schlüter a écrit :
>> On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
>>> Hi,
>>> 
>>> I've opened the voting for Automatic Property Initialization:
>>> 
>>> - https://wiki.php.net/rfc/automatic_property_initialization
>> 
>> This has the same issue as the 64bit RFC:
>> "This feature is proposed for inclusion in PHP 5.6"
>> 
>> For 5.6 we have an alpha out. We created a new release process after
>> learning that changes late in the game delay our releases and offer a
>> stronger guarantee that the following release is not in unforeseeable
>> future to make it a viable thing to delay changes by a release.
>> 
>> This is no evaluation of the feature itself.
>> 
>> johannes
>> 
>> 
> 
> Hi Johannes,
> 
> Out of curiosity I read both the Voting and Release Process RFCs and
> couldn't find any mention of a rule stating that all votes had to be
> approved before the first alpha, if I overlooked it, please correct
> me. Also, If you look at the wikipedia definition of an alpha in, I
> believe that it is still time to add features:
> 
> <quote>The alpha phase usually ends with a feature freeze, indicating
> that no more features will be added to the software. At this time, the
> software is said to be feature complete.</quote>
> http://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha
> 
> Also, isn't it to the Release Manager role to make such decisions?
> 
> I digged the archives from last month and I found this message from
> Ferenc Kovacs and Julien Pauli who are RMs:
> 
> <quote>
> Yep, that's to prepare for the future.
> We *won't* merge any RFC after the first beta. Recall that everybody.
> 
> If you now have a new RFC, ok why not accept it in the 5.6 workflow
> (even if we said no new RFC after first alpha) , let's not be too
> strict, but be warned it *has to* be merged before first beta , that
> is something like mid-march.
> For sure, no new idea can be merged after first beta, so RFC will have
> to be stabilized and voted and accepted for the mid-march dead-line.
> </quote>
> 
> The document linked is:
> https://wiki.php.net/todo/php56#timetable
> 
> The RFC was created before the first alpha, the voting phase is now
> and if the result of the vote is a yes, then it has until mid-March to
> be included. At least that's how I read it.
> 
> I am just a reader of the list, I unfortunately don't have the skills
> to participate at this level of technicity, but maybe it would be good
> for you guys to clarify the schedule and especially clarify the voting
> process in this schedule since apparently you understand the 'No new
> RFC' by alpha 1' as 'Only RFCs that got a positive vote before alpha 1
> can be in the final realease'. I think it's probably the role of RMs
> to clearly state  what the wording they use means to make sure
> everybody is on the same page.
> 
> My 2 cents,
> 
> Regards :)
> 
> Pascal

I think this should be included but I don't remember there being any 
discussion on this. Will this work with types?

public function __construct((foo) $this->x, (bar) $this->y);