Re: [PHP-DEV] [RFC][VOTE] E_WARNING on invalid container read-adccess
Le 16/08/2016 à 17:55, David Walker a écrit : I'd like to go ahead and open up the RFC to voting to the scope that it is written. Hi, At AFUP, we would be +1 on this RFC. Basically: it could/will help detect problems, and the behavior change should not cause too many bc-breaks (actually, when it does cause some, it'll - probably - mostly be by detecting problems/bugs). Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function
Le 10/08/2016 à 11:14, Yasuo Ohgaki a écrit : Hi all, This is RFC for adding session_create_id() function. Hi again, Not that many of us at AFUP discussed about this RFC (maybe it's because of the summer and holidays, or it's because not many of us need this?), but those who did all agree having such a function provided by PHP will be better than trying to implement it ourselves, the day it's actually needed -- and it's a single function without much impact or bc-break anywhere else. So, we would be +1. Thanks again for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Add session_gc() function
Le 10/08/2016 à 11:30, Yasuo Ohgaki a écrit : Hi all, This RFC is to add session_gc() function. Hi, We at AFUP would be +1 on this RFC to add a session_gc() function. Basically: there are some situations were it could be useful and it's a quite self-contained change. Thanks for you work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] New operator (short tag) for context-dependent escaping
Le 30/07/2016 à 17:09, Michael Vostrikov a écrit : Hello. The RFC 'New operator (short tag) for context-dependent escaping' is now in voting phase. Hi, Even if it could seem interesting at first, typically for beginners (hoping they use this operator instead of the current ones), we at AFUP would be on the -1 side. Basically, our main reasons: "it feels a bit too magical" and "the escape function is set globally" (both points being partially linked). In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-intern...@afup.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions
Le 27/06/2016 17:17, Aaron Piotrowski a écrit : Voting has opened on the RFC to change most conditions in extensions that raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. Hi, At AFUP, we would be +1 on this RFC, as it fits well into the path started with PHP 7.0 Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-intern...@afup.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Iterable
Le 24/06/2016 à 20:05, Aaron Piotrowski a écrit : Voting on the Iterable RFC has opened and will remain open until 7/2/16 at 11:59 GMT. Hi, At AFUP, we would be a huge +1 for this RFC: it answers a need many of us have had in the past. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
Le 10/06/2016 12:38, Joe Watkins a écrit : The vote for typed properties has been restarted. Hi, We, at AFUP, often tend to be on the "more static / strict types" side of things, and it remains this way for this RFC -- which means we would be +1 for typed properties. A few noted this was not quite "the PHP way", while the majority felt this was in line with previous changes (like scalar type declarations, nullable types...) and could prove interesting for complex applications. Judging from where the votes are right now, I'm guessing this RFC will not pass, but, in any case, thanks for your work on this! There are more "yes" than "no", so maybe it will open a path towards something, maybe a bit different, in another future version... -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] More precise float value
Le 12/06/2016 20:54, Jakub Zelenka a écrit : The vote for more precise float values is now open: https://wiki.php.net/rfc/precise_float_value#voting Hi, Not many of us at AFUP expressed their opinion on this RFC, but those who did were +1, if the only impact is on printing numbers, with no impact on (especially) performance. In any case, thanks for you work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with "Too few arguments" exception
Le 06/06/2016 09:22, Dmitry Stogov a écrit : You can find the full RFC at: https://wiki.php.net/rfc/too_few_args I encourage everyone to read the RFC and cast your vote towards whichever option you feel is the best for the language and the community. Hi, At AFUP, we would be -1 for this RFC for PHP 7.1, as it causes a bc-break without bringing much (speaking about "features") in return. Yes, it highlights (brightly) a situation in which there is probably a bug; but we think it changes behavior quite too brutally for a minor version. On the other hand, we would be +1 for this in PHP 8.0, as this would help detect/catch bugs and it is "more OK" to break BC in a major version. (I realize I'm basically repeating what others said in this very thread and/or in the one about bc-breaks in minor versions, but I'm posting anyway: one additional opinion cannot hurt, I hope) In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Fix inconsistent behavior of $this variable
Le 06/06/2016 09:18, Dmitry Stogov a écrit : You can find the full RFC at: <https://wiki.php.net> https://wiki.php.net/rfc/this_var I encourage everyone to read the RFC and cast your vote towards whichever option you feel is the best for the language and the community. Hi, At AFUP, we agree the inconsistency outlined in this RFC is quite strange and fixing it would be nice for the language. But, we are not sure this should be done in PHP 7.1 (or any other minor version, actually). Instead, some of us would be more comfortable with PHP 7.1 (or 7.2, if it becomes too late for 7.1) adding a deprecation warning. The inconsistency could then be fixed for 8.0. This way, no BC-break for 7.x minor versions on this point. Even if PHP allowing developpers to modify $this is kind of strange and they shouldn't do it, it still is existing behavior. Is there any rush of fixing this for end-users, on a minor release? In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-intern...@afup.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Nullable Types
Le 10/05/2016 à 17:22, Levi Morrison a écrit : Dmitry and I have opened [voting on Nullable Types][1]. [1]: https://wiki.php.net/rfc/nullable_types#voting_choices Hi, At AFUP, we would be +1 for having nullable types, for both parameters and return values. It often seems, with PHP 7.0, this specific feature is missing ;-) A few indicated "int?" would have seemed more familiar than "?int", but it doesn't seem like a deal-breaker; and being close to Hack is more important than being close to - say - C#. In our discussions, more (not a big margin though) were +1 for nullable types on parameters than on return values; no deal-breaker here either. Anyway, happy to see votes are going well and nullables types are more than likely coming for PHP 7.1! Thanks for you work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/
Re: [PHP-DEV] [RFC] [VOTE] Octal Interpolation Overflow
Le 29/04/2016 23:31, Sara Golemon a écrit : Voting has opened for https://wiki.php.net/rfc/octal.overload-checking Vote YES to raise a compile time warning when octal values greater than \377 are used. Vote NO to continue ignoring the overflow. Hi, At AFUP, we would be +1 for the warning: it might help detect some invalid usages of octal notation. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types
Le 17/04/2016 18:51, Bronisław Białek a écrit : We've opened the vote on https://wiki.php.net/rfc/multiple-catch Hi, At AFUP, we would be +1 on this RFC. Basically: small feature that should not break existing code and can be useful in some situations. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Voting] Null Coalesce Equal Operator
Le 24/03/2016 16:08, Midori Kocak a écrit : Remember Null coalesce Equal Operator ??= She is in voting phase now. :) https://wiki.php.net/rfc/null_coalesce_equal_operator <https://wiki.php.net/rfc/null_coalesce_equal_operator> <https://wiki.php.net/rfc/null_coalesce_equal_operator <https://wiki.php.net/rfc/null_coalesce_equal_operator>> Hi, Not many of us at AFUP (French UG) took part in our discussion about this RFC, but, by large, the majority of those who did are +y1. Basically: it feels more consistent, which we generally consider as a good thing. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Precise session management
Le 09/03/2016 10:14, Yasuo Ohgaki a écrit : Vote starts 2016-03-09-09:00(UTC) and ends 2016-03-23-09:00(UTC) https://wiki.php.net/rfc/precise_session_management#vote Hi, At AFUP, we would be +1 on this RFC. Basically: better security and pretty-much no bc-break, is a good thing. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt
Le 15/03/2016 17:11, Scott Arciszewski a écrit : I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e. make it only installable via PECL). Hi, After discussing this RFC at AFUP, we would be +1 to deprecated mcrypt for PHP 7.1 and to remove it for PHP 8.0 Removing for PHP 7.2 doesn't feel "right" (too soon? and minor versions should not remove features if it can be avoided). Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets
Le 19/02/2016 13:19, François Laupretre a écrit : Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends in 2 weeks : Monday, March 7th 00:00 UTC. Hi, We talked about this RFC at AFUP and are +1, by a huge margin. Basically: more coherence between functions, behavior that's kind of expected by many, useful feature; and low risk of bc-break. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate mb_ereg_replace eval option
Le 28/01/2016 11:02, Rouven Weßling a écrit : voting has started on "Deprecate mb_ereg_replace eval option" (https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option) Hi, After discussing this RFC at AFUP, we (all of those who expressed their mind) are +1. Basically: not a big change, consistent with what's been done for preg. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Number Format Separator
Le 13/01/2016 19:48, Thomas Punt a écrit : Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in one week's time on January 20th. Hi, At AFUP, we would be on the -1 side (by a huge margin). The "good" thing would be code that's a bit more readable, yes. But it would be harder to search in code, as there would be more than one way to write a number. Basically, it would break grep/find. Splitting numbers so they are more readable is kind of a presentation matter and, as such, could be done by an editor/IDE when displaying code, without having to modify the code by hand (actually, I'm quite surprised it's not a feature I remember seeing in any IDE). In any case, thanks for you work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline
Le 05/01/2016 10:51, Zeev Suraski a écrit : the vote is now open for the PHP 5 Support Timeline RFC: https://wiki.php.net/rfc/php56timeline#vote Hi, We've discussed this at length at AFUP, and would be +1 to extend the lifetime of PHP 5, by a huge margin. As for the duration, we would be on the 1+1 year side, by a smaller margin. Basically: - Not everyone will switch to PHP 7 right away, so extending support, especially for security, seems necessary. - But extending it for too long could give a wrong message to some users, like "no need to upgrade"; and we don't want that. - Also, after a while, we would prefer time being spent on 7.x instead of used maintaining 5.x for years. - And, in any case, some users will never upgrade, no matter how long 5.x is maintained... that's just how it is. Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Add HTTP/2 Server Push Support to ext/curl
Le 09/12/2015 19:51, Davey Shafik a écrit : https://wiki.php.net/rfc/curl_http2_push#vote Voting will end in 2 weeks, closing at 13:00 UTC on Wed 2015-12-23. Hi, At AFUP, we would be +1 on this RFC. (there has been no -1 at all on our list ;-) ) Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Void Return Type RFC
Le 29/10/2015 01:08, Andrea Faulds a écrit : Hi everyone, The vote can be found here: https://wiki.php.net/rfc/void_return_type#vote Hi, At AFUP, we would be +1 on this RFC, mostly because adding this kind of static check could help detecting a few mistakes here and there. Thanks for your work on this, and welcome back! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility
Le 20/10/2015 19:36, Sean DuBois a écrit : Time for a simple RFC (in theory)! https://wiki.php.net/rfc/class_const_visibility thanks! Hi, After discussing this RFC with other people at AFUP, we are +1. Basically, being able to define constants inside a class, to represent magic-values or the like without exposing them publicly, would be nice! And a bit more consistency with properties and methods cannot hurt. Thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Short Closures
Le 22/09/2015 03:59, Bob Weinand a écrit : Hey, or straight ahead to the vote: https://wiki.php.net/rfc/short_closures#vote Thanks, Bob Hi, After discussing this with other people at AFUP, we would be (a large majority of us) -1 on this RFC. Basically, we feel that: * This could lead to less readable code, mostly because of the usage of an operator (which is not, to some, "the PHP way") and because of the parenthesis / brackets that are optional in some cases * The "~>" operator has less meaning than "function" Keeping the old "function" syntax is, of course, nice and required -- but also means having two possible syntaxes for the same thing, which is less nice. BTW, the "automatically bind variables" didn't come up much in our discussion. And a few mentioned that "~>" could be a bit hard to type and could look a bit too similar to "->". In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] JSON number to string
Le 09/06/2015 20:23, Jakub Zelenka a écrit : The voting is now open: https://wiki.php.net/rfc/json_numeric_as_string#voting Hi, Discussing this RFC with other people at AFUP, we would, by a small margin, also be on the -1 side (for all 4 points). Still, if this was to pass, we would be +1 for PHP 7.1 ; and -1 for PHP 5.6 and 7.0. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Reserve even more type hints
Le 16/03/2015 07:44, Sara Golemon a écrit : The voting period for the Even More type hints reservation RFC is now open. Hi, Discussing this RFC with other people at AFUP, we are +1, for all five proposed types (well, even if not really types today). Like for the reserve more types RFC, this will cause a few BC-breaks here and there, but they should not be too hard to fix; and it opens doors for the future. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Reserve More Type Names in PHP 7
Le 22/03/2015 23:28, Levi Morrison a écrit : When opening the vote I did not decide when the vote would close. Unless I hear from someone specifically requesting a longer period, I will close this RFC on Friday, March 27th sometime in the evening (UTC-7). Hi, It seems I'm a bit late (I didn't see the end date before, so I just supposed it was 29/03, like for a few other RFCs for which votes started on 16/03), sorry. Still, at AFUP, we would have been +1. Even if this proposition causes some bc-breaks (and some are already there, because of STH), a new major version is the right time for this -- and those bc-breaks should not be the hardest ones to fix. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] In Operator
Le 15/03/2015 20:31, Niklas Keller a écrit : I just opened the vote for the in operator Hi, Discussing this RFC with other people at AFUP, it seems the majority of us ended up on the +1 side. The idea of a unified syntax to find whether or not something is *in* something else seems to be interesting for many. On the other hand, some noted this new operator doesn't feel like the PHP way and cannot be used as a callback (as it's not a function). A few also suggested if this is accepted, maybe it could be extended for objects in the future; with new a specific method? In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
Le 16/03/2015 18:04, Marcio Almada a écrit : I had no time to reply all emails since yesterday, but right now we are having a voting with 2 yes votes vs 16 no votes. I think we all agree that the RFC won't pass and I'm withdrawing the RFC Hi, Even though it's a bit too late: thanks for your work on this! At AFUP, we were +1 (by a rather large margin) on the idea of checking for additional arguments, considering it would help detect some (possible) future bugs. Seems we were going on the opposite direction of the votes on the RFC itself. We didn't quite reach a consensus between notices and warnings, though -- mostly because they would *maybe* have helped detect *possible future* bugs. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Generator Delegation
Le 15/03/2015 20:18, Daniel Lowrey a écrit : As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC Hi, Only a few people at AFUP discussed this RFC (I suppose it's the kind of feature not everyone will use), but those of us who did are +1. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Le 15/03/2015 17:09, Dan Ackroyd a écrit : The 'Constructor behaviour of internal classes' RFC is now in voting. Please note, it's the coding standard that is being voted on. If anyone thinks I've implemented the changes in a way that is less awesome then there is no reason the changes couldn't be improved. Hi, We at AFUP are +1 on this. Basically, more consistency is a good thing. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
Le 15/03/2015 04:23, Sammy Kaye Powers a écrit : A two week discussion period has been held for the reliable user-land CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been moved into voting. Hi, We've talked about this RFC with other people at AFUP and are +1. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Anonymous Classes
Le 13/03/2015 20:33, Philip Sturgeon a écrit : https://wiki.php.net/rfc/anonymous_classes Hi, We've discussed this with other people at AFUP, and are on the +1 side. Thanks for this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
Le 15/03/2015 16:46, Nikita Popov a écrit : https://wiki.php.net/rfc/reclassify_e_strict#vote Voting is open for ten days :) Hi, We talked about this RFC with other people at AFUP, and it seems we are on the +1 side. Basically, with strict warnings, one might wonder whether or not his code is OK. With warnings and/or notices, it will be more clear that things are not just OK. Thanks! -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
Le 07/03/2015 12:56, Thomas Punt a écrit : I'd like to put the variadic empty() RFC to vote. RFC: https://wiki.php.net/rfc/variadic_empty Hi, Discussing this RFC with other people at AFUP, we ended up on the -1 side (by a thin margin). The main reason given against this proposal was that it would not be clear (when writing/reading code) whether it would test for all empty / and or at least one empty / or -- like you explained in one of your mails. And it appears this is, at least for us, more of a problem than writing several empty() in a row. In any case, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC VOTE] Generator Return Expressions
Le 09/03/2015 17:50, Daniel Lowrey a écrit : I'd like to announce voting for the Generator Return Expressions RFC: https://wiki.php.net/rfc/generator-return-expressions#vote Hi, After discussing this RFC with other people at AFUP, it seems we (even if not many of us did express themselves on this matter) are +1. Basically, adding one information that doesn't count in the iterator and acts as some kind of final value could be interesting. Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer
On 01/03/2015 02:11, Marcio Almada wrote: the voting for the Context Sensitive Lexer is now open. Hi, After discussing this with other members of AFUP (well, not any of the implementations, as we don't really have the expertise needed for that -- but the feature as seen by end-users), we are on the +1 side for the idea. Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5
Le 26/02/2015 15:58, Anthony Ferrara a écrit : I have opened voting on Scalar Type Declarations v0.5. Please cast your vote. Hi, We were, at AFUP, +1 for the v0.3 of this RFC, and it seems we still are on the +1 side for this v0.5 Thanks for having re-vived this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Le 23/02/2015 19:15, Nikita Popov a écrit : Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into exceptions, has opened: https://wiki.php.net/rfc/engine_exceptions_for_php7#vote Hi, After discussing the main proposition of this RFC with other people at AFUP, it appears we would be +1 (by a large margin !). Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Remove PHP 4 Constructors
Le 23/02/2015 05:39, Levi Morrison a écrit : I have moved the RFC for removing PHP 4 constructors[1] into voting phase. Hi, After discussing this RFC with other people at AFUP, we would be on the +1 side, especially with the approach that goes in two steps, targeting both PHP 7 and PHP 8. We would have been farther from a consensus with the remove from PHP 7 idea -- but going in two steps, the first one being to mark those old-type constructors as deprecated, feels much better. Thanks for you work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion
Le 23/02/2015 17:06, François Laupretre a écrit : Starting the vote for https://wiki.php.net/rfc/array-to-string. Hi, We talked about this with other people at AFUP and a great majority of us agrees that the current behavior of array to strings conversions is not quite useful -- and, for several of us, when we started getting notices with PHP 5.4, it actually showed us there were bugs in our applications. So, we are +1 on this. Basically, even if notices are already bringing some useful information, we feel being more strict and explicit than that might help, here. As a sidenote, an idea that was suggested a few times was that adding some kind of __toString() method on arrays could be useful in some cases -- but this goes a lot farther than this RFC... Thanks, -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference
Le 13/02/2015 21:51, Thomas Bley a écrit : we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference Hi, We've discussed this RFC with a few other people at AFUP, and we would be -1. Our reasons are probably the same as expressed here by others: updating the (more or less internal) error-messages doesn't feel right. And one can already use his own error handler to log what pieces of data are needed. Still, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http
Le 26/02/2015 12:28, Michael Wallner a écrit : I forgot to formally declare a voting period, so I’ll do so now. Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do so until then. https://wiki.php.net/rfc/pecl_http#vote Hi, Not many of us at AFUP participated in our discussion about this proposal, but it seems we would be on the -1 side. Basically, even if a good HTTP layer is a good thing, we feel it kind of has its place more in user-land than in PHP itself. Adding this to PHP would mean more maintenance work on PHP itself, but also releases synced with releases of PHP -- which, in the end, is not that interesting for end-users, we think. In any case, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
Le 19/02/2015 10:09, Joe Watkins a écrit : The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote Hi, While talking about this RFC with other people of AFUP, we discussed about assert()... And mostly ended up against it. Still, note we probably discussed more about the idea of using assert() itself than about the RFC and the proposition of improving the existing assert() construct -- which means we probably didn't really answer the question that was asked here. Basically, the idea of adding code (assertions) directly into the code of our application in order to test for things doesn't feel right: we'd rather use (unit-)tests for that, alongside our application's code and not interleaved with it. Considering this, we kind of felt it wasn't really necessary to work on assertions and that enhancing them might encourage people to use them more -- adding more non-production code in the middle of the production-code. Also, using .ini directives to enable or disable the execution of portions of code comes with a risk: there is always a chance someone will mis-configure a server and assertions will run in production environment. Or maybe in some edge cases, an assertion could have some side-effect that would impact the code (even if it should not), making it work in development and not work in production? I hope I summarized our thoughts right -- and sorry if we didn't really answer the question that was asked. Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Remove the date.timezone warning
Le 16/02/2015 18:59, Bob Weinand a écrit : Voting period is 8 days, it will end 24th of February. The RFC is here: https://wiki.php.net/rfc/date.timezone_warning_removal https://wiki.php.net/rfc/date.timezone_warning_removal Hi, After discussing this RFC with other people at AFUP, we would be on the -1 side. Basically, even if this warning can sometimes be annoying (especially in CLI), we think having a not properly configured timezone can be bad enough to justify keeping the warning (maybe only as E_STRICT, if one really wants to hide it in some cases). Thanks, -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Parameter skipping RFC
Le 08/02/2015 09:14, Stanislav Malyshev a écrit : I'd like to announce a vote on parameter skipping RFC: https://wiki.php.net/rfc/skipparams Hi, After discussing this RFC with other people at AFUP, we would be -1. Basically, even though not having to specify the default-value for some parameters could be useful in some situations, this approach doesn't feel right and we would really prefer something like named-parameters (even if this RFC is not incompatible with named-parameters and they most likely won't make it for PHP 7.0). Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Spaceship operator RFC
Le 16/02/2015 11:58, Stanislav Malyshev a écrit : Hi! Reopen it for one day. It's quite crazy but it does not create a precedent. Andrea said she gave the RFC to anyone wishing to go on with it. If you officially take over the RFC, you are the owner, you can do that. OK, I've put it back to vote for a day. Will close it tomorrow. Hi, Thanks for reviving this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator
Le 02/02/2015 13:06, Andrea Faulds a écrit : The RFC, which contains the voting widget, can be found here: https://wiki.php.net/rfc/combined-comparison-operator Thanks! Hi, Discussing this RFC with other people of AFUP, we would be +1. Basically: adding such an operator would make things much easier when it comes to writing comparison functions. (Even though the RFC has been withdrawn, I thought posting this could help, if anyone wishes to keep working on it) -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Le 05/02/2015 21:14, Andrea Faulds a écrit : Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Hi, Even if this RFC has been withdrawn, I'm posting this here, hoping it might prove useful if someone ever tries to revive it. We've discussed this RFC quite a bit with other members of AFUP, and finally ended on the +1 side. Basically, adding type-hinting for scalars goes towards a PHP that is a bit more strict -- which seems like a good thing for us. But, at the same time, the weak mode by default means users can choose to go that way at their own pace and existing code will keep working, even if calling strict libraries. The biggest concern we've had is the declare() syntax that feels a bit weird at first. But that's not enough of a concern for us to be -1 on the RFC as a whole. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Fix foreach behavior
Le 05/02/2015 09:49, Dmitry Stogov a écrit : The RFC is turned into voting https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices Hi, After discussing this RFC with other people at AFUP, it seems we are the +1 side, on both propositions. Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Le 02/02/2015 20:11, Anatol Belski a écrit : https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. Hi, After discussing this RFC with other people at AFUP (we weren't that many to participate in this discussion -- which probably indicates not many of us care about keeping those), it seems we would be: * +1 to remove all SAPIs listed in this RFC * +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred keeping those, but a new major version feels like the right time to drop them, if the underlying libraries aren't maintained anymore. * +1 to remove ext/mssql and ext/sybase_ct * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one. Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Le 05/02/2015 21:14, Andrea Faulds a écrit : At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Hi, Just to let you know, I've written a post about this RFC on my blog, trying to present what it brings to the table and to explain why I like it: http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html Maybe another way of presenting things might help some people here to decide whether or not they think this RFC is helpful. Even if I've published this earlier today, I've written it between Thursday and Friday, so it doesn't really take into account the new ideas (new syntax propositions) that have been posted since. Please note this is *my* personal opinion, and doesn't necessarily reflect the opinion of any organization I am affiliated with. Pascal. -- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] jsond
On 25/01/2015 18:29, Jakub Zelenka wrote: Voting on jsond is now open: https://wiki.php.net/rfc/jsond Hi, After talking about this RFC with other people at AFUP, we are +1. Basically, fixing licensing problems is important in itself. This should also help having the same official JSON extension in all distributions. And, in this case, it comes without too much BC-break. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Remove hex support in numeric strings
Le 26/01/2015 21:02, Nikita Popov a écrit : Reminder: This vote closes tomorrow. Nikita Hi, Not many of us at AFUP expressed their opinion on this RFC (which is probably a sign this feature isn't used much and won't be missed ^^). Still, those who did all agree on removing this -- which means we would be +1. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
On 14/01/2015 10:18, Levi Morrison wrote: I have moved the Return Types RFC[1] into voting phase. A few changes have happened since it was originally announced but have been covered by discussion. Hi, After discussing this RFC between members of AFUP, we are +1. Once this is done, extending it to nullable types and scalar hints could be interesting too -- if the corresponding RFCs pass, of course. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
On 11/01/2015 04:02, Juan Basso wrote: I'd like to initiate a vote on this RFC: https://wiki.php.net/rfc/json_preserve_fractional_part Hi, After discussing this RFC with other people of AFUP, we are +1 on this. Being able to get back the same PHP type after encoding data to JSON and re-decoding it could be useful (thinking about strict comparison, typically), even if JSON only has one number type. And adding a new flag doesn't have much negative impact (as long as it's not enabled by default, especially for a minor version of PHP). -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Remove deprecated functionality in PHP 7
On 02/01/2015 17:04, Nikita Popov wrote: Voting on the removal of deprecated functionality in PHP 7 is now open: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes As requested, I've split this up in many individual votes, only some particularly trivial function deprecations are left as a group. Hi, After some discussions with other people of AFUP, we ended up with a +1 on all points : a new major version is the right time to remove those deprecated features (else, they'll pretty much remain in PHP forever). -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] PHP 5.7
On 07/01/2015 01:44, Andrea Faulds wrote: The voting widget and RFC can be found here: https://wiki.php.net/rfc/php57 Hi, We've discussed this RFC with other members of AFUP and while opinions have been expressed for both yes and no, it seems we are at about 2/3 of yes -- which means we would be +1. Note, though, we are mostly a community of users (which means we generally have a point of view of users) -- and there aren't many PHP contributors amongst us. Trying to summarize what we have said, on the +1 side : * PHP 5.x would be maintained (especially, it would receive security fixes) for one additional year, which would be a good thing for those who will not update to PHP 7 soon (and there are some -- still, not sure they would update to PHP 5.7 either) * Notices / deprecation warnings could help making the migration to PHP 7 easier (once you've migrated to the last 5.x minor version and fixed a few things, you'll know migrating to the next major should not be too hard) And, on the -1 side : * Even if there is no PHP 5.7, we already have something like 2 years left before PHP 5.6 stops getting security fixes -- and, taking a look at current versions usage, if one doesn't upgrade in 2 years, they probably won't upgrade in 3 years either. * Things that will break for PHP 7 will be indicated by the migration guide (and there are some automatic helper tools for some) * There are not that many PHP contributors -- which means having PHP 5.7 and PHP 7 more or less in parallel might slow PHP 7 down (not only for the initial release, but also for maintenance and evolutions later). -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Objects as Keys
On 16/12/2014 09:34, Stanislav Malyshev wrote: I'd like to initiate a vote on objects as keys RFC: https://wiki.php.net/rfc/objkey Hi, After discussing this RFC with other members of AFUP, we would probably be +1 on the idea of being able to really use objects as keys. But, considering this RFC doesn't go all the way to objects as keys (especially on the using foreach doesn't get you the object back part), we ended up on the -1 side. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Unicode Codepoint Escape Syntax
On 09/12/2014 00:51, Andrea Faulds wrote: Please read through the RFC and cast your vote if you wish to do so: https://wiki.php.net/rfc/unicode_escape Voting starts today (2014-12-08) and ends in 10 days’ time (2014-12-18). Hi, A more complete and long term approach might come from a better/deeper integration of Unicode into PHP itself -- but that won't happen for PHP 7 (it failed with PHP 6). That being said, the feature described here is quite small and concise, simple to use, useful in some situations, and shouldn't break BC too much. So, after discussing with other members of AFUP, we are on the +1 side. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] ZPP Failure on Overflow
On 02/12/2014 22:44, Andrea Faulds wrote: I’m putting the ZPP Failure on Overflow RFC to a vote. This RFC is an important prerequisite to the Big Integer Support RFC, as it ensures safety in implicit integer parameter conversions. The RFC requires a 2/3 majority, and voting starts today (2014-12-02) and ends in 10 days’ time next Friday (2014-12-12). Hi, Opinions from the community might not be the most interesting ones for this kind of RFC, but the few members of AFUP who took part in a (short) discussion about it would be +1. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions
On 19/11/2014 21:39, Andrea Faulds wrote: I am putting the Safe Casting Functions RFC to a vote. https://wiki.php.net/rfc/safe_cast#vote Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29). Hi, Judging from the discussions we've had with other members of AFUP, I'm guessing we'd kind of be +0.5 to this. Having a proper definition of what is a valid int/float/string could prove useful, especially in a context of stronger typing (like scalar type-hints, which is one case this definition would be the most helpful). This definition would have to be considered as some kind of an *official* one, though -- and not just be used for a few functions. Staying within the context of this RFC, we'd probably prefer the try_*() version of those functions, which would be useful for validations -- even if throwing exceptions from regular non-OO functions is not quite (for now?) the PHP way. Not a full +1 though, mainly because these functions only feel like half-a-step towards stronger typing. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
On 03/11/2014 22:10, Stas Malyshev wrote: I'd like to put to vote my proposal about the filtered unserialize(): Hi, After discussing this RFC with a few other people, we seem to agree that allowing some level of security-related filtering when unserializing is a nice idea -- so, we would be +1 on the principle. Some of us think raising a notice -- or, better, throwing an exception -- in case of a not-allowed class might be helpful, especially when it comes to detecting problems and unsafe input data. Still, we understand __PHP_Incomplete_Class must have been chosen to remain close to the way unserialize() now behaves. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: Should we hold two different votes?
Le 05/11/2014 00:58, Andrea Faulds a écrit : Good evening, A lot of RFCs have been rejected because, while they proposed a feature people would like, the details were problematic. This has lead to these features sometimes being considerably delayed. So, in order to do something about this, here’s an idea: Why not hold two different votes on an RFC, similar to how legislation is passed in the UK’s House of Commons? The first is on whether the general principle of the RFC is sound. Once that’s passed, it’s clear the feature is wanted, so time can then be spent scrutinising the details of the proposal and making them acceptable. Then, a second vote can be held, which approves the RFC as a whole, and its patch (like our current votes do). This way: * Authors know quickly whether a feature has sufficient support (reading internals doesn’t necessarily tell you anything, as votes and numbers of positive/negative emails rarely align), without having to necessarily have done everything before the final vote * Bad ideas are rejected sooner * Good ideas with flawed implementations may succeed in the first vote and fail in the second, meaning there’s a clear agreement that it’s wanted but not with this implementation, allowing another RFC with an improved approach to perhaps be made later Does this sound like a good idea? I really like this idea, which might help the RFC process in several ways: People (especially those who are not involved much in PHP internals now) might hesitate less before working on a principle RFC, knowing they won't have to code a feature (which might take days or more) that may just not be accepted. People not knowing C / PHP internals might suggest more principle RFCs. And if those pass with an overwhelming yes, it might be easier for them to find support from current maintainers to help work on the implementation. Also, it might be the right time to have different people voting, like: * Community (representatives of frameworks, UGs, ...), who are close to users but don't know C / PHP internals, should be able to vote on the principle RFCs. * While voting on implementation RFCs might be restricted to people who are closer to PHP -- mostly, those who can already vote today (like people with karma, or working on doc) Like you said in your last point, it also allows for a more iterative work on implementation, if a principle is accepted but an implementation is not. Though, I think there might not always be a need for implementation RFCs: if the implementation of a principle is trivial enough (like, for instance, adding a simple new function or changing the default value of a parameter), having to vote on the implementation could be a too heavy process. -- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Loop + or control structure
On 03/10/2014 22:33, Leigh wrote: Opening the vote on loop + or control structures. https://wiki.php.net/rfc/loop_or Voting will close in 1 week and requires a 2/3 in favour to pass. Remember at this stage the implementation is flexible. Hi, After talking with other members of AFUP, it seems most of us like the idea of having some way of executing code if a loop is never executed. The or keyword feels a bit odd to those who are used to the else of Twig (or other languages) -- but it's not really that much of a problem either: after a while, we'll get used to using or (or some other keyword). So, we would be on the +1 side of things on this. Still, Sara's idea of giving all loop constructs a return value indicating the number of times the loop executed feels great -- and this would probably be more flexible than loop...or I'm guessing this is why you voted no on your own RFC? -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On 25/09/2014 09:42, Dmitry Stogov wrote: Hi, The vote is opened at https://wiki.php.net/rfc/fix_list_behavior_inconsistency Thanks. Dmitry. Hi, After discussing this RFC with a few other members of AFUP (French UG), we agree *something* should be done, to get to a consistent behavior: either all, or nothing, but not half. Most of us seem to go towards disabling in all cases (which indeed means BC-break for those who were using this -- probably not that many), but it seems like no-one will be sad if things end up going the other way around. -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Remove alternative PHP tags
On 24/09/2014 20:13, Nikita Popov wrote: The vote for removal of alternative PHP opening/closing tags in PHP 7 is now open: https://wiki.php.net/rfc/remove_alternative_php_tags#vote Hi! We've talked about this RFC with several other members of AFUP (French UG), and we pretty much all agree that PHP 7 is the right time to remove these alternative tags. This might/will cause BC-breaks for a few scripts and applications, but it seems acceptable, as: * Those alternative tags are not used that much (so, not too many applications should break) * Detecting and fixing these breaks should not be too hard and can, at least in part, be automated. -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Null Coalesce Operator
On 20/09/2014 01:34, Andrea Faulds wrote: I’ve put the Null Coalesce Operator RFC to a vote: https://wiki.php.net/rfc/isset_ternary#vote It is a 2/3 majority vote and ends in a week’s time on 2014-09-27. Hi, We've discussed this RFC with other members of AFUP (French UG), and we've written quite a few mails about the ?? operator itself and a few other ideas. To summarize, we pretty much all agree that having to use isset() in order to avoid a notice is often cumbersome, and that a proposal that would allow us to write shorter code is nice. Using a new operator also feels better than changing the behavior of ?: and the ?? operator should not be hard to remember and understand. A new ??= operator might be useful, but not having it right away is OK: it'll still be possible to add it in the future, if enough people using ?? feel that ??= could help too. So, basically, +1 ;-) -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 15/09/2014 00:23, Andrea Faulds wrote: This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). https://wiki.php.net/rfc/integer_semantics#vote Hi, After discussing this RFC with other members of AFUP (French UG), we agree that improving cross-platform consistency is important, so +1. Users of a high-level language such as PHP should not, in our opinion, have to worry about the kind of differences this RFC wants to fix. Of course, changing this now might break some scripts here and there, but probably not that many of them (as it's about edge-cases for bitwise shifts, which were already giving different results depending on the platform, and odd casts) -- and PHP 7 (major version) feels like the right time to fix this. -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Removing Multiple Default Clauses in Switch Statements
Le 05/09/2014 22:29, Levi Morrison a écrit : I have opened voting on this RFC: https://wiki.php.net/rfc/switch.default.multiple#vote Levi Morrison Hi, After speaking with other members of AFUP (French UG) about this RFC, we all agree that having two 'default' cases in a switch construct doesn't make much sense -- and should cause a syntax error for PHP 7. An E_DEPRECATED warning for PHP 5.7 is also nice for end-users, as it will help anticipating the migration to PHP 7. So, basically, +1 -- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On 18/08/2014 18:41, Nikita Popov wrote: I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote After speaking with other members of AFUP (French UG) about this RFC, we pretty much all agree that a cleaner compilation process is a nice improvement. It should help us getting some syntax options that were impossible before, and there is not too much impact for developers and their existing applications. So, basically: +1 -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Move the phpng branch to master
Le 06/08/2014 14:36, Zeev Suraski a écrit : I opened the voting on the phpng RFC: https://wiki.php.net/rfc/phpng#vote Voting ends on Thursday, August 14th. After speaking with other members of AFUP (French user-group) about this RFC, here's a short summary of our thoughts: The idea of (greatly: 20-30%) improving performances is really interesting, be it for performances themselves or for the reputation of the language. That's even more true if this gets us closer to JIT in the future. Having to update all extensions is not perfect, but is not really a problem either: developers of extensions know this is to be expected for each major version of PHP -- and, after the branch is merged to master, they will still have something like two years to update their extensions. We are a bit sad this has been developed for quite some time in secret and the community has learned about it only after most of the work had been done: it doesn't really fit with the way we think about open-source. Same thing about the fact several evolutions have all been worked on in the same branch, the same RFC and the same vote, instead of each being independent from the others. We feel there might have been too much public communication about phpng and its performance improvements, before the decision of merging it was (or not) taken. Because of this, at the time of the vote, we kind of feel like we don't have much of a choice: if the branch is not merged, PHP will look quite ridiculous, as phpng is already expected by many to be used as a a first step for PHP 7. Judging from some discussions here, we are afraid the quality and maintainability of PHP's source code might suffer a bit from this merge. For us, a major version is the right time (it's going to be used for something like 10 years) to work on those. (still, easy to say, when only a few of us contribute code to PHP). PHP 7 will be a major version. It must not be released earlier than planned only to publish some performance improvements as soon as possible (even if those are great). It is important to also think about features, reworks and other major improvements: with one major versions every 10 years, it's pretty much now or never! We would prefer PHP 7 to be released as a great version in two years, rather than seeing it too early in one year. In the end, there have been two opposite opinions on our UG's mailing-list -- and both are well represented, with strong posts on both yes merge and no don't merge: * Some of us are OK to merge right now and improve things later, * While others would prefer to improve things now and merge only after. In any case, we all agree there is still a lot to be done before reaching PHP 7 ;-) -- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30/07/2014 04:31, Andrea Faulds wrote: Good evening, The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC] intdiv()” thread and the whole RFC before voting. The vote is here: https://wiki.php.net/rfc/intdiv#vote It is opened today (2014-07-30) and ends 2014-08-06. After speaking with some other members of AFUP (French user-group) about this RFC, here's a short summary of our thoughts, which may sound like an echo to the current results of the vote: * Adding a new operator for a quite specific case seems a bit overkill: it probably won't be used much * Adding a new intdiv() function: why not? Basically, adding a new operator doesn't feel OK for something that wouldn't be used often, as it has some impact on the language itself. But adding a new function feels more OK, as long as it solves a problem (it does, here), as it is only a function, with no impact on the language. As a sidenote: wouldn't using GMP solve this problem, by working with infinite precision integers instead of floats? If so and if using GMP would be a good/better idea, a note about that on intdiv()'s manual page might prove useful for end-users? -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
