Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Vote change for empty() RFC »

[VOTE] Vote change for empty() RFC

php.internals

Nikita Popov

14 years ago
Hi internals! As per Pierres request I'm posting a new voting thread for my empty() RFC. During discussions on IRC it turned out that most people would prefer to allow expressions for empty(), but not for isset(), that's why the vote now has three options: * Both empty() and isset() should allow expressions * Only empty() should allow them * None of them should accept expressions https://wiki.php.net/rfc/empty_isset_exprs#vote Thanks, Nikita

Ferenc Kovacs

14 years ago
> * None of them should accept expressions > >
just to be clear, this means keeping the current behavior as is.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Nikita Popov

14 years ago
I just closed the vote for this RFC. The result (see https://wiki.php.net/rfc/empty_isset_exprs#vote) is: * Both empty() and isset(): 3 * Only empty(): 13 * None: 4 I'm not exactly sure what the policy for votes with three options is, but given that the large majority voted for "Only empty()", I'll assume that that's the accepted option. I updated my PR to only allow expressions for empty() and added nicer error messages for isset(): https://github.com/php/php-src/pull/54 It would be nice if somebody could apply that PR, as I don't have Zend karma :) Nikita

Gustavo Lopes

14 years ago
On Sun, 13 May 2012 14:56:23 +0200, Nikita Popov <nikita.ppv@googlemail.com> wrote:
> I just closed the vote for this RFC. The result (see > https://wiki.php.net/rfc/empty_isset_exprs#vote) is: > > * Both empty() and isset(): 3 > * Only empty(): 13 > * None: 4 > > I'm not exactly sure what the policy for votes with three options is, > but given that the large majority voted for "Only empty()", I'll > assume that that's the accepted option. >
The rule is that "a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes". 13 votes in 20 is not 2/3 of the votes. So the question is whether any of the persons that voted for "both empty() and isset()" prefers "only empty()" to "none.
-- Gustavo Lopes

Pierre Joye

14 years ago
hi, On Sun, May 13, 2012 at 3:07 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote:
> The rule is that "a feature affecting the language itself (new syntax for > example) will be considered as 'accepted' if it wins a 2/3 of the votes". 13 > votes in 20 is not 2/3 of the votes. So the question is whether any of the > persons that voted for "both empty() and isset()" prefers "only empty()" to > "none.
It is not the same. As far as I can tell, this RFC (no matter which option) is not accepted and we keep the current behavior untouched. For the next time, there is an option to allow multiple choices afair. That could have avoided this problem (or introduce two results with same votes :). Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Nikita Popov

14 years ago
On Sun, May 13, 2012 at 3:14 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi, > > On Sun, May 13, 2012 at 3:07 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote: > >> The rule is that "a feature affecting the language itself (new syntax for >> example) will be considered as 'accepted' if it wins a 2/3 of the votes". 13 >> votes in 20 is not 2/3 of the votes. So the question is whether any of the >> persons that voted for "both empty() and isset()" prefers "only empty()" to >> "none. > > It is not the same. As far as I can tell, this RFC (no matter which > option) is not accepted and we keep the current behavior untouched.
I'm not sure I can follow. The vote has three options, of which two are quite similar. I don't see how the 2/3 rule for votes with two options can be applied here, in such a black&white fashion. We had at least one precedent of a vote with three options, where the option that was implemented in the end had only 59% of the votes. That was the vote for the callable typehint [1]. The three options were: * Callable: 34 * Callback: 18 * Neither: 6 I think that vote was very similar to this one. Two of the options were "in favor", but differed in the exact implementation, and the last option was "against". The only difference is that in this case one option actually has 65%, not 59%. Additionally I want to note that in this case there was a more general Yes/No vote before the more precise one, which ended with 12:2 (86% in favor). Nikita [1]: https://wiki.php.net/todo/php54/vote#doodle__form__callable_typecheck_in_arguments_choose_which_name_you_prefer

Gustavo Lopes

14 years ago
On Sun, 13 May 2012 16:15:43 +0200, Nikita Popov <nikita.ppv@googlemail.com> wrote:
> > I'm not sure I can follow. The vote has three options, of which two > are quite similar. I don't see how the 2/3 rule for votes with two > options can be applied here, in such a black&white fashion.
The fact there are more than two options should not alleviate the majority requirement. Let's say everyone who voted for empty()/isset() would prefer none to empty() only. Should this vote now pass just because you added an extra options that dilutes the votes against the most voted option? For instance, debian requires a supermajority for certain proposals independently from the number of options (see e.g. http://www.debian.org/vote/2008/vote_003 ).
> We had at least one precedent of a vote with three options, where the > option that was implemented in the end had only 59% of the votes. That > was the vote for the callable typehint [1]. The three options were: > > * Callable: 34 > * Callback: 18 > * Neither: 6 > > I think that vote was very similar to this one. Two of the options > were "in favor", but differed in the exact implementation, and the > last option was "against". The only difference is that in this case > one option actually has 65%, not 59%.
This vote is an aberration and your description is disingenuous; some people that voted for callable also voted for callback, but your description suggests that the votes for callback should all count against callable. So someone that would vote for callable and callback would actually be casting a vote against whichever of those two options that would gather more votes. The following votes were cast: callback callable neither callable, callback callback, neither If there is anything that can be learned from here is that this lack of clarity should not be repeated.
> Additionally I want to note that in this case there was a more general > Yes/No vote before the more precise one, which ended with 12:2 (86% in > favor).
Irrelevant. That vote happened before the pertinent objections had been raised (for instance empty(UNDEFINED_CONSTANT)/isset(UNDEFINED_CONSTANT) now returning false/true). And in any case, that voting was superseded by the new one.
-- Gustavo Lopes

Pierre Joye

14 years ago
hi. On Sun, May 13, 2012 at 4:15 PM, Nikita Popov <nikita.ppv@googlemail.com> wrote:
> We had at least one precedent of a vote with three options, where the > option that was implemented in the end had only 59% of the votes.
As far as I remember the final decision was more about what was actually used in the documentation.
> Additionally I want to note that in this case there was a more general > Yes/No vote before the more precise one, which ended with 12:2 (86% in > favor).
It is not 100% sure that everyone wants both to be changed. As Stas suggested earlier, it would help if you can convince one person having voted none or both to choose the empty only option, then you should be good. It is not that good in general, but for 1/3 of a voice for something like that ... :) Also let try to document how to create multiple choices vote better for the next ones. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Stas Malyshev

14 years ago
Hi!
> As Stas suggested earlier, it would help if you can convince one > person having voted none or both to choose the empty only option, then > you should be good. It is not that good in general, but for 1/3 of a > voice for something like that ... :)
AFAIK 2 of the people voting "both" (myself included) already said they are OK with "empty only". But in general, what is happening now is exactly what I was concerned about when we have started this voting thing - that decision becomes matter of formal incidents having nothing to do... well, with anything on the merits of the proposal. Support we lack one vote and do not implement it - then we didn't implement a feature because somebody who could add one crucial vote was on vacation or too busy or missed the email. I don't think it's a good situation.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Pierre Joye

14 years ago
hi Stas, On Mon, May 14, 2012 at 9:02 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi! > >> As Stas suggested earlier, it would help if you can convince one >> person having voted none or both to choose the empty only option, then >> you should be good. It is not that good in general, but for 1/3 of a >> voice for something like that ... :) > > AFAIK 2 of the people voting "both" (myself included) already said they > are OK with "empty only".
If the other one can raise his voice, then we are good.
> But in general, what is happening now is exactly what I was concerned > about when we have started this voting thing - that decision becomes > matter of formal incidents having nothing to do... well, with anything > on the merits of the proposal.
Partially correct but mostly wrong too. Let me explain it below.
> Support we lack one vote and do not > implement it - then we didn't implement a feature because somebody who > could add one crucial vote was on vacation or too busy or missed the > email.
Right now, one has one month to vote. Yes, the voting vote is only two weeks but he can always say his opinion before leaving. As of those being too busy during one month to read a RFC and vote, then that's bad for them and for php. However, the issue we are suffering is not about people being busy or being in vacation. The issue is that we are a very few amount of active developers. I'd to say maximum 5 for daily to weekly active, maximum (and I am very optimist here) 10 for monthly. And last but not least, most of the historical contributors are not active anymore, no matter how. This is the problem, not the voting. So the key is to get more active contributors and we are doing well again. Most of the top 5 contributors for this year are new contributors (except you and me :). We have to improve that too. But we can't stop to move and organize our next releases because some legacy developers have moved to other interesting projects (with all due respects). That being said, I was thinking to send notification emails when a RFC is proposed and when it enters the voting phase. A one time email for everyone then each developer has to opt out if he does not want these notifications. That should help to get some active devs voting while they are totally not interested to follow internals (bad but their choices).
> I don't think it's a good situation.
me neither, but I have a different view on it. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Anthony Ferrara

14 years ago
Pierre,
>> AFAIK 2 of the people voting "both" (myself included) already said they >> are OK with "empty only". > > If the other one can raise his voice, then we are good.
I had meant to reply to the list, but I had replied to Stas directly. I would be happy to change my vote from isset() and empty() to empty() only if that's what it would take... Anthony

Rafael Dohms

14 years ago
On Mon, May 14, 2012 at 1:16 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> I had meant to reply to the list, but I had replied to Stas directly. > I would be happy to change my vote from isset() and empty() to empty() > only if that's what it would take... > > Anthony
This would settle it, so in the realm of "action" what can we do now? Is there a rule that allows to call for a re-vote? Should start a new RFC? Or can we just alter the vote and consider this the "end of voting"? Sorry, but all this talking is running around in circles, and everything has been said. I would like to bring closure to this topic.
-- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br

Stas Malyshev

14 years ago
Hi!
> I just closed the vote for this RFC. The result (see > https://wiki.php.net/rfc/empty_isset_exprs#vote) is: > > * Both empty() and isset(): 3 > * Only empty(): 13 > * None: 4
Low turnout is kind of disappointing - either people are not interested in this feature or don't care in general. Since we have only 3 people voting "both", we should ask them what they prefer. I, for example, prefer "only empty" to "none".
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Kris Craig

14 years ago
On Sun, May 13, 2012 at 1:20 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> Hi! > > > I just closed the vote for this RFC. The result (see > > https://wiki.php.net/rfc/empty_isset_exprs#vote) is: > > > > * Both empty() and isset(): 3 > > * Only empty(): 13 > > * None: 4 > > Low turnout is kind of disappointing - either people are not interested > in this feature or don't care in general. Since we have only 3 people > voting "both", we should ask them what they prefer. I, for example, > prefer "only empty" to "none". > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
This is exactly what I was afraid of. The current voting process doesn't account for multi-question votes like this, so there's no consensus on how they should be counted (i.e. do you add all the "yes" votes and divide by the total or take the question with the most "yes" votes and divide that one by the total?). I think this would be a good time for us to reconsider my earlier suggestion of drafting an RFC to amend and clarify the voting process to allow for such scenarios. Right now, there's obviously no consensus on how to count the votes, so I think the only proper course of action would be to nullify this vote entirely and start over with just a simple "yes" or "no" question and nothing else. Since there does seem to be wide agreement that it should only be empty(), I'd say just limit the scope to that. --Kris

Pierre Joye

14 years ago
hi, On Sun, May 13, 2012 at 11:37 PM, Kris Craig <kris.craig@gmail.com> wrote:
> This is exactly what I was afraid of.  The current voting process doesn't > account for multi-question votes like this
It does. But one has to select multiple choices votes too, if he does not want to fail because some voted for one option while they would have chosen two. Also as I can understand the frustration for such tight votes, it is however a good sign that there is no real consensus nor a huge interest to change that. The previous votes taken as an example is not comparable. We decided to take the one we already use in the documentation, if I remember correctly. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Stas Malyshev

14 years ago
Hi!
> Also as I can understand the frustration for such tight votes, it is > however a good sign that there is no real consensus nor a huge > interest to change that.
16/4 is not exactly what I would call "close vote". But I think it's not the lack of consensus but lack of interest - which raises the question, if most of the PHP group doesn't care enough to vote, does it mean it is a bad feature? Is it good that we have these things decided literally by one vote or absence of one vote?
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Sean Coates

14 years ago
> which raises the question, > if most of the PHP group doesn't care enough to vote, does it mean it is > a bad feature?
I think the disinterest is more generalized than this particular vote. As far as I can tell, only 3½ members of the PHP Group actually still participate in the PHP community in any way (not to diminish their huge contributions in the past). S

Ferenc Kovacs

14 years ago
On Mon, May 14, 2012 at 12:45 AM, Sean Coates <sean@seancoates.com> wrote:
> > which raises the question, > > if most of the PHP group doesn't care enough to vote, does it mean it is > > a bad feature? > > > I think the disinterest is more generalized than this particular vote. As > far as I can tell, only 3½ members of the PHP Group actually still > participate in the PHP community in any way (not to diminish their huge > contributions in the past). > > S > >
can I ask how did you come up with that number, and who is the half man? :)
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Stas Malyshev

14 years ago
Hi!
> can I ask how did you come up with that number, and who is the half man? :)
Tyrion Lannister? (sorry, couldn't help it)
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Clint M Priest

14 years ago
Ironically enough, he's probably the only "whole man" of the Lannisters really.

Sean Coates

14 years ago
> can I ask how did you come up with that number, and who is the half man? :)
Rasmus, Andi, and Ze'ev. Andrei works with something PHP-related, sort of, still, and is only involved on occasion, so I counted him for half. The others are all names from Internets past (pardon me if I'm wrong, but I haven't seen most of them around in a long time). S

Kris Craig

14 years ago
On Sun, May 13, 2012 at 7:35 PM, Sean Coates <sean@seancoates.com> wrote:
> > can I ask how did you come up with that number, and who is the half man? > :) > > Rasmus, Andi, and Ze'ev. Andrei works with something PHP-related, sort of, > still, and is only involved on occasion, so I counted him for half. >
If he's half-man, what's the other half? Goat? Fish? Bear-pig? --Kris

Pierre Joye

14 years ago
hi Sean, On Mon, May 14, 2012 at 12:45 AM, Sean Coates <sean@seancoates.com> wrote:
>> which raises the question, >> if most of the PHP group doesn't care enough to vote, does it mean it is >> a bad feature? > > > I think the disinterest is more generalized than this particular vote. As far as I can tell, only 3½ members of the PHP Group actually still participate in the PHP community in any way (not to diminish their huge contributions in the past).
The PHP group is totally irrelevant in this process, with all due respect. It is about php.net developers. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Stas Malyshev

14 years ago
Hi!
> The PHP group is totally irrelevant in this process, with all due > respect. It is about php.net developers.
Which is what I meant - most of the developers (or committers) did not vote at all.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Lester Caine

14 years ago
Stas Malyshev wrote:
>> > The PHP group is totally irrelevant in this process, with all due >> > respect. It is about php.net developers. > Which is what I meant - most of the developers (or committers) did not > vote at all.
Or simply don't have voting rights ... Personally I would prefer to see 'empty()' remain limited to real variables.
-- 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// Firebird - http://www.firebirdsql.org/index.php