# Vote results - Thread: https://externals.io/message/53989 - Original archive: https://news-web.php.net/php.internals/53989 - Started by Stas Malyshev on 2011-07-17T09:08:39+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53989 — Stas Malyshev — 2011-07-17T09:08:39+00:00 URL: https://externals.io/message/53989#53989 Hi! Here are the results of the votes. I've split them into "PHP Group" - people that have write access to the PHP code, based on SVN karma algorithm, and "Community" - all the rest. Here it goes: Declare PHP/php as namespace reserved for PHP internals -------------------------------------------------------- Votes: 57 total, 20 PHP Core, 37 community For option PHP: PHP group support: 15 (75%), community: 28 (75%) For option php: PHP group support: 14 (70%), community: 26 (70%) This is clearly accepted. As it's docs only change, let's update the docs accordingly. 3 people from PHP group voted against: auroraeosrose,cataphract,kalle. It'd be interesting to know why, didn't hear anything on the list AFAIR. Make primitive types (string, bool, int, etc.) reserved words ------------------------------------------------------------- Removed for BC reasons, so no reason to count vote results. Add `E_STRICT` to `E_ALL` --------------------- Votes: 58 total, 23 PHP Core, 35 community Every single voter supported it, nuff said. Add option to disable POST data processing ------------------------------------------ Votes: 58 total, 23 PHP Core, 35 community Again, accepted unanimously. Support binary notation (0b1010101) ------------------------------------ Votes: 56 total, 21 PHP Core, 35 community Unanimous again! Remove magic quotes -------------------- Votes: 54 total, 21 PHP Core, 33 community For removal: PHP group support: 18 (85%), community: 32 (96%) Again, 3 people voted against: derick,salathe,zeev. Any comments? Array short syntax ------------------- Votes: 61 total, 23 PHP Core, 38 community First option (just brackets): PHP group support: 15 (65%), community: 28 (73%) Second option (brackets and colons): PHP group support: 2 (8%), community: 7 (18%) Against both: PHP group support: 6 (26%), community: 3 (7%) I think we can deem the first option passed, but not the second one. Callable type check ------------------- Votes: 51 total, 21 PHP Core, 30 community For callable: PHP group support: 13 (61%), community: 21 (70%) For callback: PHP group support: 8 (38%), community: 10 (33%) Against both: PHP group support: 5 (23%), community: 1 (03%) We have clear majority here for implementing it, but preference on the name is less clear. Personally, I strongly urge that proposer would consider not to add another mess in our documentation and call it what it was always called in our docs. Otherwise, I guess documentation team should go and fix all our docs to say "callable" now. Change rebinding behavior of closures ------------------------------------- Votes: 33 total, 10 PHP Core, 23 community PHP group support: 10 (100%), community: 22 (95%) Votes for this one are sparse, but unanimously in support. If we have no BC issues there, it's in. foreach adds list support -------------------------- Votes: 32 total, 11 PHP Core, 21 community For: PHP group support: 1 (9%), community: 8 (38%) Rejected, at least for 5.4, sorry. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53990 — Nikita Popov — 2011-07-17T09:33:01+00:00 URL: https://externals.io/message/53989#53990 · In reply to: #53989 > Here are the results of the votes. I've split them into "PHP Group" - people > that have write access to the PHP code, based on SVN karma algorithm, and > "Community" - all the rest. Here it goes: Just to clarify: Is "PHP Group" anyone with any commit access to SVN (i.e. including docs)? Or only php-src? Thanks, Nikita --- ## #53996 — Derick Rethans — 2011-07-17T15:52:41+00:00 URL: https://externals.io/message/53989#53996 · In reply to: #53989 > Remove magic quotes > -------------------- > Votes: 54 total, 21 PHP Core, 33 community > For removal: PHP group support: 18 (85%), community: 32 (96%) > > Again, 3 people voted against: derick,salathe,zeev. Any comments? Yes, of course. I really want to get rid of them, but I am afraid by doing so is that we make a lot of applications insecure, and I just don't want to do that. I think this should wait for a next major version. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53999 — Lester Caine — 2011-07-17T16:54:28+00:00 URL: https://externals.io/message/53989#53999 · In reply to: #53996 Derick Rethans wrote: > > > > […] > > Yes, of course. I really want to get rid of them, but I am afraid by > doing so is that we make a lot of applications insecure, and I just > don't want to do that. I think this should wait for a next major > version. I've got an application which relies on them for sybase type quoting on Firebird, but that will not work on PHP5.3 anyway, so I suspect that the major version has already happened. There is no money to waste time upgrading the old code base, so it will simply stay on PHP5.2 along with a few other legacy apps. This is back a little to the LTS version ... PHP5.2 IS an LTS stable point for a lot of users. -- 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 --- ## #54015 — Philip Olson — 2011-07-18T01:34:56+00:00 URL: https://externals.io/message/53989#54015 · In reply to: #53990 > > > […] > > Just to clarify: Is "PHP Group" anyone with any commit access to SVN > (i.e. including docs)? Or only php-src? It appears "PHP Group" in this grouping only includes php-src. This is not how most people interpret the vague voting RFC however, so expect a lengthy and heated discussion on this topic in the near future. :] Voting.... Regards, Philip --- ## #54024 — Peter Cowburn — 2011-07-18T08:49:01+00:00 URL: https://externals.io/message/53989#54024 · In reply to: #53989 > > Remove magic quotes > -------------------- > Votes: 54 total, 21 PHP Core, 33 community > For removal: PHP group support: 18 (85%), community: 32 (96%) > > Again, 3 people voted against: derick,salathe,zeev. Any comments? > Like everyone else, I want to see MQ gone for good. The reason for the no vote was simply that the meaning of "remove magic quotes" was not made clear. No RFC was linked on the main page, simply "Drop magic quotes". Would the process be following Philip's RFC from 2008 [1] based on the internals discussion "adieu a la magie" [2], or a total removal of anything and everything about magic quotes as originally posed in that internals thread, or something else entirely? [1] https://wiki.php.net/rfc/magicquotes [2] http://marc.info/?t=114170222600003&r=1&w=2 --- ## #54025 — Pierre Joye — 2011-07-18T09:05:46+00:00 URL: https://externals.io/message/53989#54025 · In reply to: #54024 > > > […] > Like everyone else, I want to see MQ gone for good. The reason for the > no vote was simply that the meaning of "remove magic quotes" was not > made clear. No RFC was linked on the main page, simply "Drop magic > quotes". Would the process be following Philip's RFC from 2008 [1] > based on the internals discussion "adieu a la magie" [2], or a total > removal of anything and everything about magic quotes as originally > posed in that internals thread, or something else entirely? The idea is obviously to remove it as we planed already to do it in the old trunk. Keeping BC for clean code, those relying on the mq functions to check if mq is on or off (returning always off). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54026 — Peter Cowburn — 2011-07-18T09:15:14+00:00 URL: https://externals.io/message/53989#54026 · In reply to: #54025 > > > […] > > The idea is obviously to remove it as we planed already to do it in > the old trunk. Keeping BC for clean code, those relying on the mq > functions to check if mq is on or off (returning always off). Yes, that was obviously the idea, not to remove or drop magic quotes at all but instead set, and enforce, the value to be off. Thanks for clarifying that entirely too late. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54027 — Pierre Joye — 2011-07-18T09:19:20+00:00 URL: https://externals.io/message/53989#54027 · In reply to: #54026 > > > […] > > Yes, that was obviously the idea, not to remove or drop magic quotes > at all but instead set, and enforce, the value to be off. Thanks for > clarifying that entirely too late. Too late? If you did not follow any of the internals in the last 7 years, then yes, we clarified that late... Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54028 — Peter Cowburn — 2011-07-18T09:23:50+00:00 URL: https://externals.io/message/53989#54028 · In reply to: #54027 > > > […] > > Too late? If you did not follow any of the internals in the last 7 > years, then yes, we clarified that late... My meaning was simply that trying to explain what was being voted on, after the vote has closed, is too late. I'm aware of the previous discussions on the topic on this list. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54030 — Pierre Joye — 2011-07-18T09:45:24+00:00 URL: https://externals.io/message/53989#54030 · In reply to: #54028 > My meaning was simply that trying to explain what was being voted on, > after the vote has closed, is too late. I'm aware of the previous > discussions on the topic on this list. It has been explained dozen of times before the votes, that's what I'm trying to say :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54033 — Peter Cowburn — 2011-07-18T10:05:48+00:00 URL: https://externals.io/message/53989#54033 · In reply to: #54030 > > > > […] > > It has been explained dozen of times before the votes, that's what I'm > trying to say :) And the short description on the voting page (and associated non-voting page and the [VOTE] internals thread) made no mention of any such explanations for voters. That is what I'm trying to say. I may well be the only one who voted no due to not being 100% clear on what the vote entailed. I *assumed* the vote was to set MQ to off and leave the MQ functions as they are (even the set_magic_quotes_runtime() function) but without any link to sources of what "remove" really meant for that particular vote I was not comfortable with saying yes. In summary, link to the RFC(s) and/or internals discussion(s) next time please. > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54093 — Ilia Alshanetsky — 2011-07-19T22:40:56+00:00 URL: https://externals.io/message/53989#54093 · In reply to: #53989 Stas, On the "Remove magic quotes" there seems to be an overwhelming support from PHP Core and the community for removing it. Any reason there is no definitive decision on the topic? > Hi! > > Here are the results of the votes. I've split them into "PHP Group" - people > that have write access to the PHP code, based on SVN karma algorithm, and > "Community" - all the rest. Here it goes: > > Declare PHP/php as namespace reserved for PHP internals > -------------------------------------------------------- > Votes: 57 total, 20 PHP Core, 37 community > For option PHP: PHP group support: 15 (75%), community: 28 (75%) > For option php: PHP group support: 14 (70%), community: 26 (70%) > > This is clearly accepted. As it's docs only change, let's update the docs > accordingly. > 3 people from PHP group voted against: auroraeosrose,cataphract,kalle. It'd > be interesting to know why, didn't hear anything on the list AFAIR. > > Make primitive types (string, bool, int, etc.) reserved words > ------------------------------------------------------------- > > Removed for BC reasons, so no reason to count vote results. > > Add `E_STRICT` to `E_ALL` > --------------------- > Votes: 58 total, 23 PHP Core, 35 community > > Every single voter supported it, nuff said. > > Add option to disable POST data processing > ------------------------------------------ > Votes: 58 total, 23 PHP Core, 35 community > > Again, accepted unanimously. > > Support binary notation (0b1010101) > ------------------------------------ > Votes: 56 total, 21 PHP Core, 35 community > > Unanimous again! > > Remove magic quotes > -------------------- > Votes: 54 total, 21 PHP Core, 33 community > For removal: PHP group support: 18 (85%), community: 32 (96%) > > Again, 3 people voted against: derick,salathe,zeev. Any comments? > > Array short syntax > ------------------- > Votes: 61 total, 23 PHP Core, 38 community > First option (just brackets): PHP group support: 15 (65%), community: 28 > (73%) > Second option (brackets and colons): PHP group support: 2 (8%), community: 7 > (18%) > Against both: PHP group support: 6 (26%), community: 3 (7%) > > I think we can deem the first option passed, but not the second one. > > Callable type check > ------------------- > Votes: 51 total, 21 PHP Core, 30 community > For callable: PHP group support: 13 (61%), community: 21 (70%) > For callback: PHP group support: 8 (38%), community: 10 (33%) > Against both: PHP group support: 5 (23%), community: 1 (03%) > > We have clear majority here for implementing it, but preference on the name > is less clear. Personally, I strongly urge that proposer would consider not > to add another mess in our documentation and call it what it was always > called in our docs. Otherwise, I guess documentation team should go and fix > all our docs to say "callable" now. > > Change rebinding behavior of closures > ------------------------------------- > Votes: 33 total, 10 PHP Core, 23 community > PHP group support: 10 (100%), community: 22 (95%) > > Votes for this one are sparse, but unanimously in support. If we have no BC > issues there, it's in. > > foreach adds list support > -------------------------- > Votes: 32 total, 11 PHP Core, 21 community > For: PHP group support: 1 (9%), community: 8 (38%) > > Rejected, at least for 5.4, sorry. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #54096 — Pierre Joye — 2011-07-19T22:58:02+00:00 URL: https://externals.io/message/53989#54096 · In reply to: #54093 > Stas, > > On the "Remove magic quotes" there seems to be an overwhelming support > from PHP Core and the community for removing it. Any reason there is > no definitive decision on the topic? No but some open questions, please read my replies in the other thread about this topic. Basically it is about which kind of warnings we introduce for the setter. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54097 — Stas Malyshev — 2011-07-19T23:12:53+00:00 URL: https://externals.io/message/53989#54097 · In reply to: #54093 Hi! > Stas, > > On the "Remove magic quotes" there seems to be an overwhelming support > from PHP Core and the community for removing it. Any reason there is > no definitive decision on the topic? I think there is, but I wanted to hear people that objected in case we missed some important BC issue that would kill it. So far I heard some concerns about the defaults and a concern about security impact on applications, which is valid but I think we've waited long enough and waiting more wouldn't add anything at this point. Anybody who listens doesn't rely on MQ, anybody who doesn't wouldn't listen in 10 years. So I don't see any reason not to remove it. The question here may be about the warnings, etc. My position is - warning on set(true), warning on INI value if practical (I'm not really sure I want to keep the value in config struct just for that). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227