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
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
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?
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
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
Derick Rethans wrote:
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.
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
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
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?
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
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?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
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?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.
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
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?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.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
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
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 :)
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
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_STRICTtoE_ALLVotes: 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
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
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