[PHP-DEV] Re: [PHP-DOC] [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
Hello, The PHP documentation has a separate place for detailed examples. For example: http://php.net/manual/en/book.inclued.php http://php.net/manual/en/inclued.examples-implementation.php The same could be done for ext/hash which today lacks an Examples section: http://php.net/manual/en/book.hash.php This way the function's docs (hash_hkdf() in this case) remain as reference material while detailed examples live elsewhere. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Mar 7, 2013, at 1:00 PM, David Soria Parra d...@php.net wrote: On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote: On 03/07/2013 09:01 AM, Anthony Ferrara wrote: So my proposal is to slow down for a minute and not call this RFC accepted or not until we can come to some consensus as to if it classifies as a language change or not... Better to clarify for the health of the project than to plow through and risk causing further strife... And how do you propose we do that? Vote on it? Will that vote need 2/3 as well? I think most of us accepted that language-level changes meant syntax changes. Things that add new features to the language itself. I think the only thing requiring a 2/3 vote would be the decision on wheather to enable it by default or not. As long as it's in ext/ and not enabled a 50% should be sufficient. Shouldn't we be focusing on how this makes PHP better? And not nitpick about a percentage point or two? This makes PHP better. Please, PHP, add it to 5.5. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Mar 7, 2013, at 1:58 PM, Anthony Ferrara ircmax...@gmail.com wrote: Philip, Shouldn't we be focusing on how this makes PHP better? And not nitpick about a percentage point or two? Well, this passed with 62.8%. Property accessors failed with 60.7%. The target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9% isn't? I think the point of this discussion is that rules are rules for a reason. You can't be high and holy and deny one RFC judiciously, and then hand-wave and say the next RFC doesn't matter because the intention is there (or whatever rationale is). Either we stick to the rules, or we throw them out and install a BDFL. Either way, I don't care. I just think the current they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is deeper than BS, it's dangerous and is actively turning away contributors (as well as harming the project)… Hello Anthony, Good points. And the vague release/voting RFCs also contribute to this. And FWIW, I think PHP needs a BDFL, but we'll have to convince the one potential candidate to agree. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5
On Nov 28, 2012, at 2:08 AM, Pierre Joye wrote: hi, On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin indey...@gmail.com wrote: I voted no, (b) We should mention deprecation in manual as hard as possible, we should mention it in ext/mysql/config.m4 and any other place we can reach. Then, at some point (I'm fine with 5.6, but 6.0 would do also), we should just move it to PECL, without using E_DEPRECATED That's exactly why we should use E_DEPRECATED now and not in 5.x+1. Also no way to kill it in 5.x, that would be worst than anything else. The idea of adding E_DEPRECATED now, and then removing it in PECL, is not an opinion held by everyone. That being said, let not start this thread, every argument has been mentioned many times already. Let vote. The idea of moving it to PECL is not represented in the vote. But it's something to consider as it's a real possibility. It could both symbolize that we are serious about not using ext/mysql, and considering most Linux distros would simply switch to offering the PECL version, it'd probably not break much. Worth thinking about, at least. I'm not yet certain what we should do but this PECL topic is intriguing. Hopefully a few others will weigh in with their related thoughts. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
Thanks everyone, I didn't remember thinking about this so was impulsively curious. Dug a little now, so here's what happened: Proposal to internals (July 14, 2012) with discussion July 14-18: -- Thread: http://markmail.org/thread/kewdoz3dowrr7rfv Summary:Seemed okay, discussed more how than why, and more yes than maybe approved. Conclusion: No clear decision was reached. The patch: -- Patch: https://github.com/php/php-src/pull/132 Pull: http://git.php.net/?p=php-src.git;a=commitdiff;h=c9eb641 Summary:Mostly a technical/patch related discussion there, several tweaks, then pulled. Conclusion: Merged/pulled into master on August 4, 2012. What happened: -- - The PHP logo GUIDs were removed, and replaced with data URIs in phpinfo() and friends. - BC: Removed four *_logo_* functions, and GUID usage. - E_DEPRECATED was not used beforehand, nor doc updates, they were simply removed. FWIW, also no RFC. It's understandable how a minimally used feature can be changed and removed without much worry/thought. But, they appear to be the only functions removed in 5.5, and this helps it feel even easier to not break BC for this not-so-important change. Proposal: I propose we revert this change. Future consideration might include E_DEPRECATED for these functions in 5.5, although I am not proposing that part. Seems sensible, though. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On Nov 20, 2012, at 10:34 PM, Stas Malyshev wrote: Hi! The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when We make a lot of effort to do this. But it does not mean we should be blindly and stupidly following the rigid rules even when it makes zero sense in practice. We made sense, and are not being blind and stupid. You may disagree but I don't understand why this discussion has to become so harsh. it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. It's the inconsistency that bothers me. I think a rule like Never remove a ~function without it first emitting E_DEPRECATED can be followed 100% of the time, and don't see this as a bureaucratic rule but instead think this consistency would make PHP better. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 16, 2012, at 12:55 AM, Rasmus Lerdorf wrote: On 11/16/2012 12:51 AM, Patrick ALLAERT wrote: Rasmus, As per the RFC: adding E_DEPRECATED only in mysql_connect(), mysql_pconnect(). Which means only one error (normally) by request. I still don't see the point of using E_DEPRECATED like this for an entire extension. And I think it will hurt more than it will help for an extension this heavily used. It is going to encourage people to simply turn off that warning because they will get it on every single request which means they will never see the more subtle and granular E_DEPRECATED warnings from other parts of their code. Most front page google results for E_DEPRECATED are questions about how to hide these errors. This thought has put me over the edge and into the land of not having E_DEPRECATED for ext/mysql in 5.5. Let us prepare for this first as we are not ready. Seriously, we are not ready. And it makes me wonder about E_DEPRECATED as a whole. But this seriously makes me wonder if we should add something like how_do_i_make_my_code_more_awesome(). That may look insane (well, the function name is) but imagine it saying Stop using ext/mysql and then users hear about this, run it, and ask Wordpress Dude, this would be more awesome without ext/mysql and so on. Brainstorming. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
The main argument is that we haven't actually made it clear in the manual that the extension is going to be deprecated. There is a user note on http://www.php.net/manual/en/book.mysql.php and a This extension is not recommended for writing new code on http://www.php.net/manual/en/intro.mysql.php As Anthony mentioned, this is a very weak best-practice type of message that we are only barely whispering here. To go from that to start throwing deprecation warnings on what is perhaps the most heavily used PHP extension ever is a rather drastic step. Your argument seems to be, Well, there is no point documenting it because people won't read it anyway, which may be true, but we haven't actually tried that yet and for something like this I think it should be the first step. I wanted to clarify that it was intentional to not use the word deprecated in the documentation because it's not deprecated. However, the documentation for *every* ext/mysql function begins with a pink box that says it's discouraged, and these boxes suggest alternatives via mysqli/pdo_mysql. Whatever the case, we'll update the documentation now. It'll clarify that one day this extension will be deprecated. The only question here is the how and when but that's not a showstopper for the docs. As for the ext/mysql-mysqli conversion script. It's outdated and difficult to find but we'll make an official php.net version and promote/update it so eventually it'll become awesome. It's certainly not ready today. I suspect people will also want an ext/mysql-pdo_mysql version. No promises there… :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Where did the _logo_ functions go?
Hello geeks, Why does PHP 5.5 remove the *_logo_* functions? Is this a security related move? Shouldn't these emit E_DEPRECATED errors in 5.5? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Incomprehension with preg_match and utf8
On Nov 5, 2012, at 8:55 AM, Rasmus Lerdorf wrote:
On 11/05/2012 08:41 AM, Jean-Sébastien Hedde wrote:
On Mon, 05 Nov 2012 08:04:06 -0800, Rasmus Lerdorf ras...@lerdorf.com
wrote:
I think the documentation is wrong on that. In Unicode mode [[:alnum:]]
actually becomes \p{Xan} which should match Unicode chars as well, but
only if PCRE was compiled with Unicode support. So I suspect you don't
actually have a Unicode-capable PCRE build in some cases there.
-Rasmus
I will report the bug to the package maintainers (remi, debian too...).
Is there anyway for us to avoid those wrong builds ?
I don't see how.
Hi geeks,
Does anyone have a suggestion on how the documentation should be
updated? The quote is from here:
http://php.net/manual/en/regexp.reference.character-classes.php
With the quote being:
In UTF-8 mode, characters with values greater than 128 do
not match any of the POSIX character classes.
A few simple/related facts:
- PCRE_UCP exists as of PCRE 8.10
- Gustavo mentioned the related PHP change on Oct 3, 2010 (not sure
what PHP version, and googling for 87a237342 turns up empty,
and I miss SVN version numbers)
Anyway, how should this be documented?
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] an configure option to enable-all
On Sep 17, 2012, at 8:30 AM, jpauli wrote: On Mon, Sep 17, 2012 at 2:48 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, Sep 17, 2012 at 9:59 AM, jpauli jpa...@php.net wrote: I'm confused.. --enable-all is already supported, just like --disable-all ? -Hannes AFAIR no :) We have a --disable-all , but no --enable-all. I'm +1 to add such an option if possible :) Can you please explain to me how it is not working? ~/Sources/php/php-5.3 (PHP-5.3) $ ./configure --enable-all configure: error: Cannot find enchant And no, ext/enchant is not enabled by default. So the answer is : there is --enable-all switch , but it's not listed in the --help output Hello all, Interesting, I didn't think it existed but now realize why. It's not documented and it's not very useful. There's an old feature request (I wrote it so am surprised I forgot this exists) about differentiating between --with and --enable, along with checking if those are actually available on the system: https://bugs.php.net/24337 https://bugs.php.net/33186 Awhile ago Rasmus mentioned an idea about creating a shell script that'd check which options do (and do not) pass configure. I'm not sure how to do that but maybe someone else does. Just imagine being able to enable all possible extensions available on a system.. great for 'make test' :) As for the original question, yes you can do that. For example, this will enable all extensions except for enchant: ./configure --enable-all --without-enchant Much like --disable-all allows enabling specific extensions: ./configure --disable-all --with-enchant Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing users along ...
On Aug 1, 2012, at 7:01 AM, Johannes Schlüter wrote: On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote: The default if it's not included in the .ini is ON, but the sample .ini's both switch it off, and that is what the distributions follow when creating a clean install. ALL that was required when the problem was identified was that ?= was handled in PHP5.3 the same way it IS now handled in PHP5.4 and the problem would not exist. This is an example of not thinking through to production a simple change in the core PHP ... The default are the compiled in values. The provided ini files are suggestions with comments for improving the configuration above the default. Those values aren't the default for exactly the reason you identified. If distributions force those values on you complain there. And no, we won't change the core language (?= like in 5.4) in 5.3. There should only be bugfixes, no feature changes. If you want to help please test 5.5 snapshots before the release and identify possible issues there. As Rasmus and others said we try hard to make migration simple while allowing evolution to happen, sometimes we fail, that can only be fixed before a release, we can't change the past, yet. One problem here is that we do not distribute a php.ini file with default values. The what is the default value? topic is real and comes up often. Is it time we get back to our roots and include a file like the old php.ini-dist? And become friends with distributions to suggest real default values to be used all across the world? Today it feels dirty to mention default values in the PHP world as really this concept does not exist. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] get_magic_quotes_gpc() returns false instead of 0
Hello everyone, The following bug report brings up a good point: https://bugs.php.net/61784 The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now it returns boolean false. Instead it should return 0. Fixing this feels like a bug fix, which would go in 5.4.1. Thoughts? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0
On Apr 24, 2012, at 9:43 AM, Stas Malyshev wrote: Hi! https://bugs.php.net/61784 The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now it returns boolean false. Instead it should return 0. Fixing this feels like a bug fix, which would go in 5.4.1. Thoughts? I do not see a reason to hold 5.4.1 for this. The less people beginning to rely on this bug the better, and this is a critical time. The impact of this BC break feels larger considering MQ is enabled by default in PHP 5.3 and below. This change shouldn't damage the RC QA process as all this does (tm) is change the return of false to 0. And considering that the magic quotes feature is removed, this change should not affect other code. Oh, sometimes it's nice that more people use == versus ===. ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0
On Apr 24, 2012, at 4:46 PM, Stas Malyshev wrote: Hi! The less people beginning to rely on this bug the better, and this is a critical time. The impact of this BC break feels larger considering MQ is enabled by default in PHP 5.3 and below. I understand but a) nobody should be using magic quotes anyway and b) holding release for 5.4.1 because of a very minor issue with easy workaround doesn't seem productive for me. If we hold release for each such thing, we'll never have 5.4.1 at all. I don\'t understand why get_magic_quotes_gpc() and get_magic_quotes_runtime() get such a bad wrap. People using these functions are not using magic quotes, but instead they (most) are writing code that will work in environments that have it enabled. This helps code work in PHP 5.4 and below, as opposed to only PHP 5.4 and above. And yes, the number of people that use \=== false\ here is small I reckon. But this is a BC break in a BC function. Something feels very wrong about that. So I understand that we cannot hold a release for every bug and that we have known bugs in every release, but will we revert this change after it exists in two PHP releases? Whatever the case, this also means we\'ll have to document this change… and here I was trying to be lazy. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On Apr 18, 2012, at 1:34 AM, Hartmut Holzgraefe wrote: On 04/10/2012 06:20 PM, Adir Kuhn wrote: Hi folks, today I read this post, I think that some points are valid, follow the link for you guys as stuff like this comes up again and again (although not in as epic lenght as this one) i've been thinking whether it might make sense to have some PHP Gotchas, how they came to be, and why we can't simply fix them FAQ section in the manual or wiki? If nothing else it would at least help with dealing with this kind of rant (nothing new here, move along, your concerns were already covered in ### in great detail), but also might help that would indeed want to understand why some things are as they are. I'd rather proactively own this kind of discussions than just jump into them whenever they arise elsewhere … Hello Hartmut, Agreed, and I think it belongs in the manual. An example (not being proposed as such, but is a rough idea): Why are function naming schemes seemingly random? PHP glues many different API's together, and sometimes this gets messy. PHP leans towards the C variant which is why the likes of strlen() vs str_replace() exists, and … As opposed to our current approach, which is via mailing lists and typically RTFM. or BC. Read archives. or the like. Ack! And also include possible solutions/recommendations like this PHP FAQ entry about haystack,needle ordering, which includes the following text: A simple rule of thumb is as follows: Array function parameters are ordered as needle, haystack whereas String functions are the opposite, so haystack, needle. And thankfully there are already a lot of sites to steal the questions from, and often answers live within their user comments. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Apr 17, 2012, at 4:08 PM, Christopher Jones wrote: On 04/17/2012 03:50 PM, Stas Malyshev wrote: Hi! sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? I have a problem that we don't have understanding of what is the goal of this whole vote setup. What is it for? What we will be doing with it? And please don't say it says so in RFC - it is not a goal. Stas, I'm with Ferenc on this. We just need one or two sentences somewhere in the wiki saying how non-contributors can get vote karma. The sentences should give the physical process and what kind of people we will give karma to. The problem is that the voting RFC does not define who can vote. It contains two parts: 1. Those with SVN [sic] access (but how does karma come into play?) 2. Those without (how do we provide such rights? to whom?) If these are to be answered (they should) then I don't think an RFC can be edited like that (people already voted on it), so suspect we'd need a new RFC to replace it. Fun! I suspect most people voted Yes for that RFC thinking it'd mean less noise on this list while not caring about the details. That's only a guess. But trouble is, defining the Who is the most difficult part and a big reason why general consensus is preferred. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Apr 16, 2012, at 6:21 PM, Ferenc Kovacs wrote: On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig kris.cr...@gmail.com wrote: On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs tyr...@gmail.com wrote: Just to play devil's advocate (Satan and I go way back), what about people who are established PHP developers but who generally don't participate in the development/discussion of PHP core? An argument could be made that, as the users of PHP, they should be able to have some say in its development. That's not my position, mind you; I'm just throwing that premise out there to see if it holds up. =) could you please open a separate thread for that? btw. regular participant of internals discussions is one of the reason on which group someone can get voting karma. so if that is provided, anybody have a chance to get join the decision making process. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Why would that be a separate thread? Isn't that what we're talking about? I.e. determining who gets voting access and who doesn't? I just ask for clarification on how the community representatives (which is defined in the accepted voting RFC) can get their karma. You are talking about changing the requirements for somebody to be able to participate in the voting, thus changing/extending the original RFC. The voting RFC is unclear but aside from that, there are two non-vcs accounts with voting karma today: User: damz: Damien Tournoud - d...@damz.org User: hywan: Ivan Enderlin - ivan.ender...@hoa-project.net Not saying they should or should not, but just saying. And I'm not sure how/when they received the voting karma but it happened. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
On Apr 5, 2012, at 8:22 PM, Rasmus Lerdorf wrote:
On 04/05/2012 07:55 PM, Sébatien Durand wrote:
IMHO, PHP is a great template language. This is what makes it so simple
and powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with a more
elegant and a shorter implementation.
For example : % and %= or {% and {{ ?
What do you think, guys ?
It is well past April 1.
Here's Rasmus proposing ?php back in 1997, for PHP 3:
http://marc.info/?l=php-internalsm=90279104403805w=2
Discussion ensues, and we end up with multiple tags. Too bad. ;)
Oh, and here's a list of possible possible options from back then,
taken from that thread:
1. ? code ?
2. ?{whitespace} code ?
3. ?php code ?
4. % code %
5. (1) and (3) combined using some fancy hard-to-code
scanner with dedicated XML support.
6. ?_ code _?
7. _ code _
8. : code :
9. code
10. ?: code :?
11. ?? code ??
12. [ code ]
13. { code }
Anyway, just a brief out-of-context look at the past. Woot!
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIT commit mails
On Mar 2, 2012, at 10:36 AM, Derick Rethans wrote: Hi! Can we please fix the GIT commit mails before we move anything else over? +1 Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
On Mar 1, 2012, at 4:17 PM, Ángel González wrote: On 02/03/12 01:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon The option to use a variable as target for the break/continue. Ie. you no longer can do break $var; or continue $var; It's not telling you that you can do that, so the docs don't seem wrong. :) I like this logic :) Also, the docs are updated in SVN, and will show up ~tomorrow. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
The mirrors have not yet updated, which is why the announcement linked specifically to docs.php.net (which builds the docs 4x daily[1]) for several entries. So while not perfect… the mirrors will update tomorrow, and will include additional information. Also, a few people are making migration54 commits while I type this message. :) Regards, Philip [1] https://wiki.php.net/doc/builds On Mar 1, 2012, at 4:18 PM, David Muir wrote: I noticed that too. The migration guide is also missing a lot of stuff. A quick overview: http://au.php.net/manual/en/migration54.changes.php: content missing http://au.php.net/manual/en/migration54.new-features.php: missing a lot of new features listed elsewhere http://au.php.net/manual/en/migration54.functions.php: missing links and documentation for several functions http://au.php.net/manual/en/migration54.class-constants.php: claims that there are several new class constants, but none are listed http://au.php.net/manual/en/migration54.methods.php missing links and documentation for several methods http://au.php.net/manual/en/migration54.new-extensions.php nothing listed http://au.php.net/manual/en/migration54.extensions-other.php The following extensions can no longer be disabled during build configuration: but only one empty list element Cheers, David On 02/03/12 11:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] get_magic_quotes_* != deprecated?
Hello! Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
On Mar 1, 2012, at 6:26 PM, Adam Harvey wrote: On 2 March 2012 09:56, Philip Olson phi...@roshambo.org wrote: Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. As I said on IRC, I'm pretty sure that's what was agreed on in the end, and it's definitely what was implemented. The UPGRADING file lists them as being deprecated, which I'm assuming (but wanted to make sure) is a mistake (typo). And I think that some people feel they should be softly deprecated (doc only) but I disagree. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini
Hi Richard, I'm a little confused. Showing E_NOTICE errors is already the default with both php.ini-* files. What does this RFC change? Are you proposing that the PHP default value (without a php.ini) be modified? ; error_reporting ; Default Value: E_ALL ~E_NOTICE ~E_STRICT ~E_DEPRECATED ; Development Value: E_ALL ; Production Value: E_ALL ~E_DEPRECATED ~E_STRICT Regards, Philip Ref: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/php.ini-production?view=markup -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
Hello Pierre, I mean that the ereg extension is deprecated, yet we cannot disable it while compiling PHP. In other words, ereg() and friends always exist in PHP, and emit E_DEPRECATED errors upon use. We should have the option of creating fatal undefined function errors… basically. Currently this exists for ereg: --with-regex[=TYPE] So I guess we want: --without-regex Even though --disable-ereg would feel more natural. Regards, Philip On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote: is it not emulated using pcre now? as in, the ereg library is not used anymore On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson phi...@roshambo.org wrote: Hi geeks! We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
Hi! This thread has veered off-course. So to summarize: (1) ereg is deprecated, and usage is discouraged (2) It emits E_DEPRECATED errors as of PHP 5.3 (3) We cannot disable/remove ereg at compile time (today) I'm suggesting we alter (3) so that we, the people who compile PHP, can optionally remove this extension from our PHP 5.4+. This means adding --without-regex to go along with --with-regex, which is the current compile-time option for ext/ereg. Any objections? Regardless of deprecation status, this option should be available. Or if not, why? Regards, Philip On Jan 10, 2012, at 10:41 AM, Pierre Joye wrote: Can you please carefully read what I wrote? Thanks. I said: the deprecation is only an information via the documentation as in not adding noises to the language without any good reason. On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye pierre@gmail.com wrote: what I mean is that, as far as I remember, the deprecation is only an information via the documentation. We did not want to break BC and all that as it is now emulated through pcre. no, we deprecated it, and albeit it was a discussion to un-deprecate it, we kept it: I think we have enough reasons to keep it deprecated as we have much better alternative (pcre) which we want to recommend to the users. http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54 -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disabling ereg
On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote: On 01/10/2012 11:33 AM, Philip Olson wrote: Any objections? Regardless of deprecation status, this option should be available. Or if not, why? The main reason is that we are not done removing all the dependencies. This is a large deprecation that is going to require the process to span multiple versions. We could add a way to disable it, but it is going to break some extensions in ways that are not obvious to the user. Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like the wise choice, and adding --without-regex then as well. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] disabling ereg
Hi geeks! We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Wiki account application? [Re: [PHP-DEV] CS random values]
On Jan 5, 2012, at 6:56 AM, Tom Worster wrote: On 12/29/11 2:03 PM, Philip Olson phi...@roshambo.org wrote: Hi Tom, I fully support a one-method-to-rule-them-all for generating random sauce. Long ago I created an incomplete RFC on the subject, but please feel free to ignore and create a new/better one. There are a couple of old related RFC entries, actually: - https://wiki.php.net/rfc/get-random - https://wiki.php.net/rfc/functiongetentropy I suggest you apply for a wiki account, and it'll be approved with RFC karma, and then you can create the RFC. Thanks, Philip. How do I apply for a wiki account and RFC authoring privileges? (I googled but did not find.) Hello Tom, Your wiki account has been approved, with RFC namespace karma granted. The registration page alludes to this by requesting that you write the webmaster list about what you'll be working on. I'll update that page to make it clearer. https://wiki.php.net/start?do=register Have fun :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CS random values
snip As a noob here, what should I do next in order to pursue my objective? Is this what the PHP RFC is for? Hi Tom, I fully support a one-method-to-rule-them-all for generating random sauce. Long ago I created an incomplete RFC on the subject, but please feel free to ignore and create a new/better one. There are a couple of old related RFC entries, actually: - https://wiki.php.net/rfc/get-random - https://wiki.php.net/rfc/functiongetentropy I suggest you apply for a wiki account, and it'll be approved with RFC karma, and then you can create the RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] news.php.net archive
On Nov 23, 2011, at 11:45 AM, Stas Malyshev wrote: Hi! You mean hosting our own, or using some third party service? Usually I prefer http://www.mail-archive.com/internals@lists.php.net/ Unfortunately not all of our lists are mirrored there. Well, yes, I know there are various places where PHP lists are archived. My point is if we have official archive on news.php.net why not make it usable? :) Or officially declare some third-party archive as official if we can't. In several respects, we've been using marc.info as our official third-party archiver for many years. - The http://php.net/ mailing list search goes there - http://php.net/mailing-lists.php archive links go there But, it's worth noting that not every news.php.net listing is archived at these third-party sites. And for what it's worth (not much), I tend to use markmail.org. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl sqlite
On Nov 16, 2011, at 5:34 AM, Johannes Schlüter wrote: On Wed, 2011-11-16 at 13:35 +0100, Ferenc Kovacs wrote: On Wed, Nov 16, 2011 at 12:53 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. 5.4 is not yet released so PHP core is still the primary source for that extension ;-) you mean the pecl package description? I can change it, but where should it point to? sqlite3? or simply unmaintained? I would go for unmaintained. SQLite2 isn't maintained upstream for a few years. People can get the code if they have need to migrate or such, but other than that ... there's no good and simple migration path to something else. SQLite3 uses different APIs, different storage format and has a slightly different SQL standard interpretation. We need to make pecl/sqlite work with 5.4, as currently it does not. I forget the details (and the related patch) but did work on one with Johannes many months ago. The last step (which failed) was to get pdo_sqlite2 to work with the shared PECL variant, IIRC. Then, make a release. Moving something to PECL should require that the PECL extension work with the distribution that it was [re]moved from. Otherwise, it was not moved. Johannes probably assumed I adjusted/committed the patch, and made a pecl/sqlite release, but he forgot that I forgot to do this, and I have since lost said patch and progress and most memories. Sorry :] Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Time zone database shut down by legal threat
On Oct 6, 2011, at 3:24 PM, David Zülke wrote: FYI: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. David P.S. I hope Google/IBM/Oracle/whoever just buys those guys and then fires everyone. I spent this past week correlating PHP release dates and version numbers with celestial alignments, and can now guarantee that this lawsuit will implode immediately before the upcoming Uranus at Opposition event. Therefore, we are safe. Regards, A fellow Olson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
I'm not familiar enough with Mercurial to properly vote, but am guessing we'll move to Git. Git is popular because Github is popular, and Github is popular because it's awesome. But I think we should skip git.php.net and mirrors/bridges, and simply move to Github. And this means people who maintain Git for a living would maintain it, while we can focus on developing PHP. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session_* removal in 5.4
On Jul 25, 2011, at 1:57 PM, JJ wrote: While looking over the release notes for 5.4a1 (http://www.php.net/archive/2011.php#id2011-06-28-1) I noticed that the related session_* functions had been removed. As I interpreted it, this goes against the spirit of the release RFC for x.y+1.z releases, specifically: - Backward compatibility must be kept - API compatibility must be kept (user land) The removal of these functions makes sense (to me) but I think in order to respect the release RFC we should either: a) defer the removal of session_* functions till the appropriate release b) update the RFC nomeclature to cover this use case (as Florian pointed out, the current wording leaves it open to interpretation) I do realize I'm late to the party (sorry) and I'm not sure if it's too late to revert course on this specific change...but I think the session_* removal change will make the upgrade process more difficult because of its' far-reaching impact. In reality, PHP 5.4 does not follow the aforementioned release RFC as it breaks a lot of BC. It follows part of it, but certainly not all. If the session_* functions are restored due to BC, then a lot of other old stuff will need to follow along. Here are a few options: (A) Rename 5.4 to 6.0 ... :) (B) Remove all BC breaking changes from 5.4 (C) Change the release RFC (addendum?) (D) Mention that 5.4 does not fully follow the release RFC, and why I suspect a version of (D) will be implemented at this point, and 5.4 kinda sorta existed before the RFC. A difficult decision. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Jul 22, 2011, at 9:32 AM, Alex Howansky wrote: Just curious, if the trait property is set to private what happens? Ooh, good question. PHP Fatal error: baz and foo define the same property ($zoo) in the composition of baz. However, the definition differs and is considered incompatible. And while people have traits on the mind, please also review the three open bug reports which also discuss how trait behavior should be defined: https://bugs.php.net/search.php?search_for=traitcmd=display Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Magic Quotes in PHP, the Finalle
On Jul 18, 2011, at 7:39 AM, Daniel Convissor wrote: Hi Folks: We all want to see Magic Quotes go away. Discussions on this list indicate several people are concerned with doing this in a safe and orderly manner. [1][2] To this end, I have posted an RFC at https://wiki.php.net/rfc/magicquotes_finale Please read it through, think about it, then post your opinions to the mailing list. I'm not sure about the version change cycle (5.4 vs 5.5 vs 6.0), but regarding this part of the RFC: 'removal' What do people think should happen here? Please discuss. That's a key point as it's not a simple matter, especially considering several functions and settings exist. I reckon we all now agree that get_magic_quotes_*() should remain but return false. But for example, what about people who use set_magic_quotes_runtime() and set it to false? Should we punish these people for the sake of a cleaner break from our beloved magic quotes? Maybe. I think the current patch would simply remove it. Where is the current patch, and what does it do? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On Jul 17, 2011, at 5:31 PM, Stas Malyshev wrote: Hi! On 7/17/11 3:03 PM, Richard Quadling wrote: Why bother having defaults if you don't use them. Err, well, the way PHP ini system works you always have defaults - something is always stored in the hash. His point was that you consider the distributed php.ini-* files to define the default values, as opposed to the actual defaults. Defaults are defaults for a reason, and they should not be dismissed. My local ini file is 6 lines long. Works perfectly. And you rely on magic_quotes being on, right? Then you have peculiar definition of working perfectly. Nobody here said they rely on magic quotes, and that is not related to what a default value means, or how they are handled. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On Jul 17, 2011, at 5:56 PM, Stas Malyshev wrote: Hi! On 7/17/11 5:46 PM, Philip Olson wrote: And you rely on magic_quotes being on, right? Then you have peculiar definition of working perfectly. Nobody here said they rely on magic quotes, and that is not related to what a default value means, or how they are handled. We're discussing magic quotes. The quote was My local ini file is 6 lines long. Works perfectly.. So either one of these 6 lines resets magic_quotes to 0 - which proves my point - or Richard considers application relying on default of magic quotes - which is on - working perfectly, which is just wrong. What is the proven point? That people shouldn't use magic quotes? Nobody here is arguing with that. But dismissing the fact that magic quotes is still enabled by default, because we distribute php.ini files that disable it, doesn't help. Now, saying it's worth killing despite it being enabled by default because it's bad and has been throwing E_DEPRECATED errors since PHP 5.3.0, and that our distributed php.ini files disable it, now that's an entirely different story. Such an argument would also look up our old php.ini-recommended settings and see it was disabled there as well. But fact is, nobody has done that, nor has there been a proper discussion or RFC on this topic for 5.4. The vote was premature. Would it have turned out differently had we done it properly? Probably, but at least we'd have a proper reference point for why we removed a security feature that was still enabled by default. And to be clear, I am not arguing for or against its removal, but rather, am arguing against how it was handled. Throwing 10 separate topics (some with and without RFCs) into one thread is a recipe for non-discussion. That's what happened here, with magic quotes removal being a part of it. /rant Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote results
On Jul 17, 2011, at 2:33 AM, Nikita Popov wrote: On Sun, Jul 17, 2011 at 11:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecating ext/mysql
Hola friends, Nice feedback so far, and the PHP documentation will begin implementing the ideas presented here, and focus on mysqli but also recommend pdo_mysql. Therefore, the ext/mysql documentation will be improved to strongly recommend the preferred alternatives that have existed since PHP 5.0.0. We'll work on the finer details but it feels like procedural mysqli is a better fit to live alongside the ext/mysql examples, although we don't want to confuse people. Maybe geeks here have ideas regarding this, but a clear useful clutter-free solution will be worked out, which may include adjusting the CSS and involve creative linking. I'll add an example or three soonish. However, there has been some confusion within the PHP community, so to help ease these concerns: - This proposal only deals with documentation/education... so it can be described as an official 'soft deprecation' (no errors or code changes) - When (if?) this extension emits errors, or is removed, is not part of this proposal - There is a 100% chance that additional tasks and ideas will be discussed in the future, which might include: - A conversion tool/guide - A wrapper - A PECL extension - Talking to distros/hosters and apps like wordpress - ... - php.net understands that ext/mysql is popular, and we're handling this with extra care and heck, parts of *.php.net is powered by ext/mysql - Seriously, no need to panic We'll document the reasons why the other MySQL extensions are preferred, but if people want to use the old ext/mysql API with PHP 9.0.0 (just an example) then I'm guessing an old geek out there will make that possible. We, however, will do our best to convince users to move towards the preferred and supported methods, and hopefully write better code along the way because honestly, that's the ultimate goal here. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On Jul 11, 2011, at 5:20 PM, Stas Malyshev wrote: Hi! On 7/11/11 5:09 PM, Philip Olson wrote: this previously accepted RFC is not about removing magic quotes. And I'm the author of said RFC. It deals with PHP 5.3 which removed get_magic_quotes_*() so this old RFC restored them into both PHP 5.3+ and PHP 6. Yes, it's not exactly what is being talked about here. It's more like this RFC: https://wiki.php.net/rfc/removal-of-deprecated-features slightly modifying the patch there according to your proposal (not emit E_DEPRECATED on gets). But this topic (removing magic quotes from 5.4) was not proposed on this list, so the vote feels premature. The only related RFC on the matter involves PHP 6, and it isn't specific to MQ. Granted we all don't like MQ, but this security feature is enabled by default today so skipping discussion to a simple vote for removal feels wrong. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Jul 13, 2011, at 9:35 AM, Hannes Magnusson wrote: On Tue, Jul 12, 2011 at 20:02, David Soria Parra d...@php.net wrote: On 2011-07-12, Pierre Joye pierre@gmail.com wrote: hi, As of now I do not think we should allow this change, whether the RFC is accepted or not does not matter as it will badly break BC. Unless there is a patch allowing this change without affecting existing code (main point being namespaced code working smoothly), this RFC should be rejected. Cheers, I think this change has too much of an impact on backward compatibility. As long as we don't have a concrete implementation, I think we should let string, int not be reserved words. Argumentes were already presented. ps.: Pierre you might want to consider changing your vote in the wiki This thread is an excellent example why attempting to reach consensus by discussing things is important. Voting should be considered as an desperate last resort, not the primary mechanism. http://producingoss.com/en/consensus-democracy.html has several very related points. And each topic deserves its own thread, whereas this [original] thread lumped 10 separate topics together. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sudden spike in wiki registrations
On Jul 11, 2011, at 8:11 AM, Ferenc Kovacs wrote: On Mon, Jul 11, 2011 at 1:00 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, Jul 11, 2011 at 12:48, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jul 11, 2011 at 12:18 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jul 11, 2011 at 12:07 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, Jul 11, 2011 at 12:03, Hannes Magnusson hannes.magnus...@gmail.com wrote: It is very hard to detect which php group a person belongs to, our karma system doesn't work like that. We can easily detect if an account is an php.net SVN account though. And the wiki can tell you if a person has write access to that specific page. Most external users have assigned write groups, qa, rfc, web. These are the people who have requested access to these areas. I was under the impression the vote plugin respected the write permission acl to that page, so a user would need to have write karma to that namespace to be able to vote. Does it have no builtin functionality like that? Answering my own question; No, it doesn't. http://www.dokuwiki.org/plugin:doodle2#authentication -Hannes I checked the source, if the permissions are set correctly, then the required code change is minimal: in the php-wiki/dokuwiki/lib/plugins/doodle/syntax.php file we have to modify the render and castVote methods to check $this-isAllowedToEditEntry($fullname) and thats it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu of course the explicit group checking would be better, because currently we have votes under rfc namespace where some users have write access as they proposed/wanted to propose some rfc but they shouldn't . I think we should be able to differentiate the voters manually this time. But implementing those voting RFC rules before next time would be ideal. -Hannes after some discussion on irc, we agreed that for a quick fix for the wiki we should only allow voting for the following groups: - phpcvs : this is a fake group, every @php.net user is part of it. - voting: this group isn't exists yet AFAIK, we should add everybody to this who are allowed to vote, bu don't have svn account. my patch is on gist: https://gist.github.com/1076035 if you think its fine, it could be commited, I don't have karma for the wiki. ps: I also allowed the wiki admins to access the voting features just in case. Greetings, I didn't test it, but made the commit. What can go wrong? :) Also, I'm not sure how often the wiki pulls from SVN. And people have expressed different interpretations of the voting RFC regarding who can vote so I suspect this overall topic will persist However, the above changes have been made that hopefully fixes this bug. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sudden spike in wiki registrations
On Jul 11, 2011, at 3:48 PM, Hannes Magnusson wrote: On Tue, Jul 12, 2011 at 00:34, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 7/11/11 3:20 PM, Hannes Magnusson wrote: The idea Stas proposed of leaving the votes untouched and just hide those specific votes during rendering of the vote results is very silly to me. Manually summerizing the votes like has been done in the past on many RFCs into with karma and without results would make much more sense to me, especially since there are so many registered votes already. Well, yes, maybe that'd be even better. If anybody with shell access could get me the raw data files at the end of the vote (should be in data/meta directory with .doodle extension) I could easily write a script that summarizes it. That won't be a problem. Matching against SVNROOT/global_avail shouldn't be a problem either to apply whatever SVN restriction rules needed. The patch fixed a bug where the voting mechanism was not in sync with the passed voting RFC. It's closer now to most peoples interpretation of said RFC. Changing this would, I'm afraid, require changing the RFC which I suppose means an amendment [with a new vote] of some sort. I don't know how bureaucracies work but imagine that'd be what is needed here. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On Jul 8, 2011, at 11:30 PM, Stas Malyshev wrote: Hi! I've created a voting page for the features in 5.4 TODO list for which we need to find consensus. Please go there: https://wiki.php.net/todo/php54/vote and vote! See also links to relevant RFCs on the TODO page: https://wiki.php.net/todo/php54 If something is unclear or you notice a mistake, please write me. Greetings, I removed the \remove magic quotes\ RFC link from this todo/vote page because this previously accepted RFC is not about removing magic quotes. And I'm the author of said RFC. It deals with PHP 5.3 which removed get_magic_quotes_*() so this old RFC restored them into both PHP 5.3+ and PHP 6. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] deprecating ext/mysql
Greetings PHP geeks, Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now. The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this. This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means: - Add notes that refer to it as deprecated - Recommend and link alternatives - Include examples of alternatives There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here. What this means to ext/mysql: - Softly deprecate ext/mysql with education (docs) starting today - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 - Add pdo_mysql examples within the ext/mysql docs that mimic the current examples, but occasionally introduce features like prepared statements - Focus energy on cleaning up the pdo_mysql and mysqli documentation - Create a general The MySQL situation document that explains the situation The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
AFAIK that got into it, but the fixes for the related crashes did not. Nope, not until alpha2... but it's something to look forward to, and it's another reason for people to continue testing future alpha releases. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Jun 29, 2011, at 7:43 AM, Paul Dragoonis wrote: On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 08:10, Stas Malyshev a écrit : Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? I also tried to access a bug linkg and bug.php?id=xxx failed to work. Has there been a data problem ? A recent backup was restored minutes ago, so these bugs are back again. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Jun 28, 2011, at 9:57 AM, Stas Malyshev wrote: Hi! On 6/28/11 9:55 AM, Derick Rethans wrote: On Tue, 28 Jun 2011, Stas Malyshev wrote: I'm actually surprised it isn't in there. I did write that document some eons ago. But anyway, let's add it then :) OK, as soon as we are all agreed on Thursday and it's there I'll shift the schedule for next releases so it'll actually be on Thursday, though I'm not sure why would it actually matter :) The day an alpha/beta is released doesn't feel important, unlike stable releases, but I suppose consistency has its good points. :) I think the main point is to wait for bugs.php.net, which is making real progress and should be available Thursday. Also, it's important to clarify that the [soon-to-be-popular] built-in web server is not part of this alpha because the alpha was tagged a few days before its addition. I think repackaging would be worth it for this case, but waiting for alpha2 is feasible. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] voting rfc
On Jun 20, 2011, at 5:15 AM, David Soria Parra wrote: Hi Internals, we have been working on getting an rfc together on how to deal with votes on rfcs. We aim to provide a simple mechaism for votes while still maintaining freedom on how to do votes and how to work on rfcs. I want to move forward on the voting and release RFCs, so we can move forward on the 5.4 process. Therefore I call for votes on the voting RFC. The RFC can be found here: https://wiki.php.net/rfc/voting You can vote here: https://wiki.php.net/rfc/voting/vote Votes are open until Monday 27.06.2011. Please clarify the who can vote aspect of this RFC, which is: The proposal here is for two audiences to participate in the voting process: * People with php.net SVN accounts that have contributed code to PHP * Representatives from the PHP community, that will be chosen by those with php.net SVN accounts * Lead developers of PHP based projects (frameworks, cms, tools, etc.) * regular participant of internals discussions Does this mean that a php.net account holder must have 1+ commits? How are Lead developers determined exactly? Do they nominate themselves? Does each name require an official vote with a two week waiting period? And what's a regular participant of internal discussions? One post per week/month/year? And only the internals@lists.php.net mailing list applies? I voted against this RFC partly because the above is not clear. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP patches
On Jun 20, 2011, at 7:01 AM, Robert Eisele wrote: Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Greetings Robert, Considering the number of patches you've already shown, I think applying for an SVN account would work better as it'd give you full wiki access. We can worry about karma (commit rights) later. - http://php.net/svn-php Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Jun 15, 2011, at 11:34 PM, dukeofgaming wrote: On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS pascal.court...@nouvo.comwrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. I really mean the question, regardless. It's difficult to say, but there are a total of 1,568 php.net accounts. The karma[1] rules aren't straightforward to parse but quickly it shows at least 194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to php-src within the last 365 days. Those numbers include tests, so the number of ~active core developers appears closer to 10-20. Of course this doesn't include other parts like PECL and documentation but enough hastily created and probably misleading statistics for today. As for the point of the question, php.net could certainly use more contributors and ideally we'd clone Felipe. A lot. [1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup [2] http://svn.php.net/viewvc/php/php-src/ Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Migration of SVN commit access to SSL
Hello everyone, Please keep this off-topic discussion on a single list, and in this case, php...@lists.php.net. Thanks :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
To get back to the improve docs part I'd gladly collect the artifacts, mails, wiki entries, etc of this effort and try help create this contribute page Pierre spoke of. Here are a couple of resources to help with this: - https://wiki.php.net/doc/scratchpad/wheretohelp - http://www.php.net/get-involved.php Both sources are considered rough drafts, and are in need of organization/combining and examples. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. If the PHP+Windows community developed a reliable system that built [most] all PECL extensions, then we would link to that within the PHP Manual. And if such a system was moved to a php.net server, then DLL download links could also be added to each individual pecl.php.net page. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
On Jun 7, 2011, at 10:11 AM, Pierre Joye wrote: On Tue, Jun 7, 2011 at 6:15 PM, Philip Olson phi...@roshambo.org wrote: I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. If the PHP+Windows community developed a reliable system that built [most] all PECL extensions, then we would link to that within the PHP Manual. And if such a system was moved to a php.net server, then DLL download links could also be added to each individual pecl.php.net page. There is an easy way to build pecl extension and yes, pecl.php.net will be the place to provide them as well. In the meantime I uploaded them in the link I pasted earlier. But it happens that things can happen when people actually do the work, and not only complain endlessly in all possible channels. And this is a call for someone or some people to do the work by raising a hand, posting an RFC, writing code, whatever it takes. But I think people assume either it's going to eventually happen, or that php.net is happy with the current situation. In other words, we need an official progress report and position on the manner. Thoughts? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
On Jun 7, 2011, at 11:10 AM, Pierre Joye wrote: On Tue, Jun 7, 2011 at 7:53 PM, Philip Olson phi...@roshambo.org wrote: And this is a call for someone or some people to do the work by raising a hand, posting an RFC, writing code, whatever it takes. But I think people assume either it's going to eventually happen, or that php.net is happy with the current situation. In other words, we need an official progress report and position on the manner. Thoughts? There is an official report and that's phpize support being almost complete, that finally two persons seem to be willing to help with the web frontend parts of the job. Wiki sections with the progress will follow as well. So please do not interfere with that as it could be finally take off and the last we need is even more confusions and politics. Once it is place, I will make the change in the docs accordingly. My intent is to push progress and gain clarity. But about linking some random, uncontrolled and especially ones provided by the initial poster in this thread in our documentation is an absolute no go. The reasons are numerous and quite obvious if you have followed the archives. I'm happy to hear progress is being made. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 5, 2011, at 8:20 AM, Pierre Joye wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Hello everyone, The following categorizes bundled/enabled/core, and lists extensions as they stand today (compiled via snaps). I don't exactly know what this means, but writing this feels appropriate: - Bundled : An extension that is bundled * ./configure --enable-ext (or --with-ext) is available but required * Not sure how best to compile this list, separated by --enable/--with - Bundled-enabled : Same as bundled, but enabled by default * ./configure alone includes it * 5.3: Core,ctype,date,dom,ereg,fileinfo,filter,hash,iconv,json,libxml, pcre,PDO,pdo_sqlite,Phar,posix,Reflection,session,SimpleXML,SPL, SQLite,sqlite3,standard,tokenizer,xml,xmlreader,xmlwriter * 5.4: Same as 5.3 except 'SQLite' was removed * External requirements: libxml2, Others? - Bundled-core : An extension that cannot be disabled * ./configure --disable-all does not exclude it * 5.3: Core,date,ereg,pcre,reflection,SPL,standard * 5.4: Same as 5.3 * External requirements: Others? Of course this does not apply to Linux distributions, but we don't [directly] control that. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JSON array/object syntax
Greetings, It'd be beneficial if we waited to discuss this topic until after Sean proposes an RFC this weekend. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On Jun 2, 2011, at 3:08 AM, Sebastian Bergmann wrote: Am 01.06.2011 14:44, schrieb Johannes Schlüter: I mentioned this before: I like the Ubuntu model: * One development branch for the next version * One current version * One long term supported version +1 +1 Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Enable pecl_http by default (or, always), and bundle APC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Jun 4, 2011, at 6:00 PM, Rasmus wrote: On 06/04/2011 09:03 PM, Scott MacVicar wrote: On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. And OAuth2 is simple enough that an extension really isn't needed for it. OAuth1 was painful and the extension helped a lot. But all the painful bits that the extension takes care of are gone in OAuth2. Ideas for how and where to document PHP+OAuth2? Like, should we keep ext/oauth documented as is but expand it to include plenty of OAuth2 information? That may be confusing... hmmm Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOMNode::getAttribute()
Does anyone know of a particular reason it is not documented? (I'd be happy to document and provide the ridiculously simple patch of returning NULL...) Greetings Matt, Documenting DOM is messy/tricky (and underdocumented), but: - http://php.net/domelement.getattribute Here's one option to begin helping out with the PHP documentation: - https://edit.php.net/ And please write php...@lists.php.net for additional documentation related details and/or questions. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Jun 2, 2011, at 8:01 AM, Peter Lind wrote: On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. We all have our bad days and times when pressing submit fast feels like a good idea, but we do cover the topic here: - http://php.net/reST/php-src/trunk_README.MAILINGLIST_RULES It's good to digest this every so often, especially as a thread grows. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On Jun 2, 2011, at 1:19 PM, Sean Coates wrote: If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is clearly not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water. As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP. I share this concern, and it applies to future topics and discussions. I think you creating this RFC would be helpful, and that we as a group should respect the desired timeline for proposing this alternative RFC (I assume over the weekend?). We won't be forgetting this topic (it feels like people are panicking like we will) so if said alternative isn't available or doesn't gain traction then the current [adjusted] RFC should be implemented. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. But while we're here, pman is another option: $ pear install phpdocs/pman $ pman mysql_connect That'll show the mysql_connect() documentation as a local man page. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wiki editing privileges
On May 31, 2011, at 11:05 PM, dukeofgaming wrote: Hi, I remember having wiki editing privileges not so long ago, I was going to enter and add the entry for discussions at https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore. Would it be too much to ask to have them enabled?. I don't think anyone [intentionally] took away wiki editing rights, but you now have full access to the rfc namespace. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
On Jun 1, 2011, at 7:30 AM, Ilia Alshanetsky wrote: On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates s...@seancoates.com wrote: This discussion seems to lack real-world examples… Derick wrote: I'm still -1 on it. It makes absolutely unreadable code (yes, also in JavaScript with f.e. MongoDB). Here's an actual snippet from my production code (which interfaces with ElasticSearch): http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html If you consider this readable, you're fare more literate than I will ever be (-: Using JSON syntax would only maybe make it more readable, and then only because you would probably not format it on so many lines ;-) Maybe that could be a contest. Who can make this the prettiest, using either a proposed or current syntax. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Reminder: Pls add your votes here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote Who is allowed to vote?, are userland votes still going to count?, if so, how does one qualify as userland voter?. I think the one that is active can be a voter. Or maybe the ones that have any karma on php environment is considered a voter. I'm choosing to ignore this voting mechanism because it feels wrong. And besides, this RFC is outdated and still being reviewed for comments. In other words, nobody knows what they are voting on. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On Jun 1, 2011, at 12:43 PM, Pierre Joye wrote: On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson phi...@roshambo.org wrote: I'm choosing to ignore this voting mechanism because it feels wrong. We always voted based on php.net accounts (@php.net that is), whether it is a good thing or not is another question and unrelated to this RFC (for one, I consider that non php.net people should have a voice, iirc). But this discussion started off so well with true brain storming and ideas coming to light. People started discussing the pros and cons, people saw and began understanding the different angles, and then some people grew tired and forced a premature vote. Yes it got a little messy, but such is life. --voting. And besides, it's rare that a tallied vote is required because typically a real consensus can be reached. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing some cruft
On May 28, 2011, at 10:42 AM, Daniel Brown wrote: On Sat, May 28, 2011 at 06:05, Kalle Sommer Nielsen ka...@php.net wrote: expose_php = Off? I think what he and others mean is that they want the option to leave the logo, credits, et cetera, completely out of the build at compile time. We also have other possibilities here (this is not a proposal, but rather, a list of options/ideas to ponder): 0. Do nothing 1. Disable expose_php within the distributed php.ini-* files Trivial, but changing [at least] php.ini-production is a real possibility. 2. Disable expose_php by default within PHP We could do this too. Default === when no php.ini file is used. 3. Remove the specific PHP version from the exposed PHP header There are security concerns although I'm not sure what implications (BC?) or real help this would offer. For example, version information can be deciphered by other means (e.g., logos and credits change over time) but maybe it's a help because, for example, displaying phpinfo() requires direct user action. See also #4. 4. Change its behavior and usage For example, phpinfo() relies upon expose_php for both the logo and credits information to be displayed. However, the phpinfo() output clearly exposes PHP (along with the version) regardless of the expose_php setting so we could instead embed the logo into phpinfo(), and display credits as per phpcredits(), instead of relying upon expose_php for this as done currently. In other words, expose_php could be off yet phpinfo() behavior would remain close to the same with either a little extra markup, or appended credits near the license. But this raises the question: Why do we have magical logo and credit guids? 5. And a performance review People are concerned with performance issues (e.g., images loaded into memory) although I'm not sure what real performance is lost (some have made guesses). Is there a real issue with performance here? How does it compare with, let's say, loading an additional extension? If so, how can it be helped? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
A few notes worth mentioning:
- That RFC moved from fail to 'under discussion' a few weeks ago, although it
hasn't been edited
- Most people are now for it, or at least that's the general feeling on IRC
(#php.pecl) these past few weeks
- Discussing it is on the 5.4 TODO ( https://wiki.php.net/todo/php54 )
And since I voted against it last time around, here's my take (quoting myself
here from the recent 5.4 thread):
I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or
may not) slow adoption, but since other such changes are being made then let's
do it. And while explicit code (e.g., array()) is nice, many people are
familiar with array shortcuts.
I think the main question is if related features (e.g., inline array slicing)
should also be implemented. Once upon a time the $arr{} syntax almost did that.
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
Hello everyone, There are differing opinions on this matter so I'll base a conclusion on current SVN: - Both (INF==INF and INF===INF) are true in PHP 5_4 because it's the correct behavior - PHP 5_3 will continue as is for BC reasons (INF==INF = false, INF===INF = true) So unless something changes then this is how INF will be documented. And please inform the documentation team if this changes. ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On May 31, 2011, at 3:06 PM, Rasmus wrote: On 05/31/2011 02:59 PM, Michael Shadle wrote: Forgive me for injecting my $.02 here but what is the original reason for changing the most basic language syntax to be a little bit shorter? Is it hurting anyone to type out array() or something? I think it is silly that shortening array syntax is up for discussion but ensuring Unicode compatibility isn't a higher priority. Not to mention named parameters in functions. Or Consistent naming for functions str_* vs str*, needle/haystack ordering, etc. If you're wanting to augment or change fundamentals of the language why not clean some stuff up there first? Because most of those can't be done without breaking millions of lines of code out there. And a couple of people worked on Unicode for years and got very little support. That is not a small project. This short syntax for arrays is probably the most requested PHP feature right now and we have a working patch that doesn't break any existing code so the effort involved is minimal. If you have a working patch that solves the Unicode issues, by all means, show us. And because this mailing list thread is about 'short syntax for arrays' and not the other items you mentioned. If you're interested in another topic, or have a proposal, then please do so as a different thread. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need karma for committing test patches
On May 27, 2011, at 3:40 AM, Alexey Shein wrote: It seems my last letter didn't came to the list, resending it. So this is new version of this patch - with curl_multi_exec involved and accordingly changed tests. Let me know what you think about it. Additionally, I found another test case (actually two) not handled yet (see attached test case in second file): 1) If fp of non-existant file is setup to stderr and is closed before calling curl_close() it causes glibc memory error 2) if I additionally unlink file before curl_close() - it causes segfault (fie not found in io_write.c or smth like that) Greetings Alexey, I'm unable to provide useful comments for this patch, but am CCing the official ext/curl maintainer (Ilia) and you now have karma for committing tests. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] INF behavior
Hello geeks, A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following: ?php $inf = pow(0, -2); var_dump($inf); // float(INF) var_dump($inf == $inf); // bool(false) var_dump($inf === $inf); // bool(true) ? That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true. Is this is how we want it? And how should this be documented/explained? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
@all Can we decide on decoupling ?= before going back to the general short tag matter? It feels like decoupling ?= from short_open_tag will happen. And I've not seen objections or reasons for not doing it, so think we can safely assume that it's been decided. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
apparently somebody else brought up the shortag(specifically the ?= tag) topic again, and I've noticed that you moved the rfc from declined to In discussion recently (https://wiki.php.net/rfc/shortags?do=revisions), so I would like to know that are these rules still hold, or did something happened since this decision? I couldn't find the suggested clarification in the docs either (maybe looked at the wrong place) The topic split into a few directions with decoupling ?= from short_open_tag being one of them. I moved it to In discussion because the decoupling idea gained traction although afair it wasn't discussed at length, but it's part of the 5.4 'to discuss' TODO[1]. Regards, Philip [1] https://wiki.php.net/todo/php54 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 6:02 PM, Stas Malyshev wrote: Hi! We once had a matrix showing test results per setup (OS, phpversion, per configure switches) but it was someones pet project and the code has long since been lost (he looked years ago). Maybe such a beast would be useful. We can do a table saying which tests fails where in the wiki right now... Okay let's have a look after we receive more reports. And collaboration may be needed for several of these fails although opening a bug report for each doesn't feel ideal. Other ideas? A I tried this, it may be that, my OS is weird, ah I see, oh nice idea let's try... Eureka! type dialogue comes to mind. Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 results, and always receives snapshot results? For example, snapshot test results (5_3 and trunk) are configured to _not_ go there today. I think it's an excellent idea. 5.2 is not going to be fixed anyway, we need 5.3 and trunk much more. I replaced 5.2 with 5.4 for FC, and we now allow 5.3.7-dev and 5.3.99-dev snaps. However, I'm unable to determine why 5.3.99-dev tests aren't posting to the list but at least 5.3.7-dev do now. Speaking of 5.3.99, how about we rename it to 5.4? The trunk being 5.4 or 6.0 debate feels over. ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On May 11, 2011, at 4:00 AM, dukeofgaming dukeofgam...@gmail.com wrote: On Wed, May 11, 2011 at 4:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/11/2011 01:39 AM, dukeofgaming wrote: The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up) I see. I have actually read most RFCs, but I do feel something is meesing. Perhaps if RFCs were categorized by potential release in the wiki —or alternatively, an additional Intented PHP version field— then agreements coud get easier, because I don't see consistent PHP version information for RFCs that could lead to an actual roadmap. snip Agreed, the RFC wiki namespace is cluttered, and for example year[s] old empty entries even exist there Apply for a wiki account, then start hacking :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 12:20 PM, Johannes Schlüter wrote: On Wed, 2011-05-11 at 18:03 +, Andi Gutmans wrote: Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). +1 Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 12:50 PM, Stas Malyshev wrote: Hi! Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already. I don't think it's closing feature discussion. We can have another alpha after the discussion, or more than one. I can see the value of having _something_ right now to signify we mean it this time, but that something would definitely not be anything near final and we can take features in after the discussion is done. The alpha release proposal by Andi contains the text: I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 3:56 PM, Rasmus Lerdorf wrote: On 05/11/2011 02:10 PM, Philip Olson wrote: So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) There are still quite a few test failures in trunk. Some of them are also in the 5_3 branch. In some cases the tests are simply bad. In a few the test case contains binary data that got mangled in the move to Subversion. It would be nice if just 1 in 10 people reading the list here would grab both trunk and 5_3 and run make test in each tree and then fix at least 1 test each. We would have no test failures by the end of the day other than a few tricky ones. If an alpha release will encourage this, great. If we could get people to just do it on their own without the alpha, even better. And yes, I know the tests take forever to run. Get yourself a fast machine with an SSD, and remember you can run partial tests using: make test TESTS=ext/hash for example to just run the tests for the hash extension. Also, when a test fails, cd into the ext/hash/tests directory and you will see .out, .exp, .diff and .php files for the failed test. That is, the output, the expected output, the diff between them and the php script itself extracted from the .phpt file containing the failed test case. And if you can't figure out how to fix a test, post the details here. I'd love to point some of the obvious talents and energy of this list towards the code. If you don't have an svn account for committing your fixed test, go to http://www.php.net/svn-php.php and fill in the little form at the bottom there and put in the test that you fixed and a 1-liner about how you fixed it and I will set you up with an account right away. Info on how to check out the code from svn is here: https://wiki.php.net/vcs/svnfaq This is a great challenge. Long ago I decided that failed tests are expected in PHP, because out of the ~100 or so times I've run it these past n years, it has always (afair) failed. Changing this fact by having it pass would change peoples (at least my) perception that running 'make test' is a waste of time, as is (was) looking into why they failed. For example, just now trunk gives me 55 failed tests and 17 expected fails with a vanilla build. We once had a matrix showing test results per setup (OS, phpversion, per configure switches) but it was someones pet project and the code has long since been lost (he looked years ago). Maybe such a beast would be useful. Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 results, and always receives snapshot results? For example, snapshot test results (5_3 and trunk) are configured to _not_ go there today. Regards, Philip [1] http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php [2] http://news.php.net/php.qa.reports -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 9, 2011, at 2:38 AM, Stas Malyshev wrote: Hi! I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen. I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or may not) slow adoption, but since other such changes are being made then let's do it. And while explicit code (e.g., array()) is nice, many people are familiar with array shortcuts[1]. And on a related note for those at home, function array dereferencing[2] has already been implemented in trunk. Also, there could probably be a discussion dedicated to arrays as other features/shortcuts like slicing has casually been discussed. [1] https://wiki.php.net/rfc/shortsyntaxforarrays [2] https://wiki.php.net/rfc/functionarraydereferencing Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: rlms
On Apr 15, 2011, at 2:23 AM, Hannes Magnusson wrote: 2011/4/1 Hannes Magnusson hannes.magnus...@gmail.com: 2011/3/31 Pål-Kristian Hamre ms.shared+lists/php-...@redpill-linpro.com: We need access to this repository to commit changes to the infrastructure: https://svn.php.net/repository/systems/ Verified. He is working on bringing the wikibox back to live, and will be committing configs and stuffz for the box to systems/ Poke Done. Welcome to the PHP team, Pål-Kristian Hamre :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Greetings Moriyoshi and all, Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet. Also the wiki is up again so: - RFC: https://wiki.php.net/rfc/builtinwebserver - Patch is here: http://gist.github.com/835698 Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote: On 30.03.11 21:36, Dan Birken wrote: As for adding other string functions, I agree, I think there are a lot of them that would be great to add. starts_with ends_with for sure. Both str_startswith and str_endswith have been suggested in the past: http://marc.info/?t=12164723011r=1w=2 I recently got around to merge them into a largely unfinished extension so they are archived somewhere safe: https://github.com/mj/php-ext-str I see str_contains() on the TODO there. I've always wanted in_string() so am glad to see a similar item. Using strpos() for this task feels dirty, much like using arrpos() for arrays would ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
On Mar 31, 2011, at 9:43 AM, Brian Moon wrote: How would str_contains() be different from strstr()? They differ in the return type $instr = (bool)strstr($string1, $string2); done. No need for a new function. Well, to be clearer: bool str_contains( haystack, needle [, case_insensitive = false ] ) string str[i]str( haystack, needle [, $before_needle = false ] ) The main differences: - Return value is a bool - No ordinal value conversions (I assume) - No === usage worries/requirements - Intuitive name Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
On Mar 31, 2011, at 9:55 AM, Sebastian Bergmann wrote: Am 31.03.2011 17:52, schrieb Rasmus Lerdorf: Argh! Everyone should be forced to learn a bit of C. Like many PHP functions, the name and argument order is right out of libc. If you type man strstr at your (non-Windows) prompt you get a nice little description of what it does. And if you install pman you just do pman strstr and get PHP-specific documentation. Although I disagree that adding a C prerequisite to PHP ends this discussion, using pman is a related topic which can be installed like so: pear install doc.php.net/pman Then, simply 'pman in_array' or similar will open local php man pages in shell. However, the pman files have not been updated for awhile so we'll look into this. Oh, guess we should create a 'pman pman' too. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extensions to traits
On Feb 9, 2011, at 9:55 PM, Ben Schmidt wrote: - Don't write long e-mails to a mailing list, write an RFC http://wiki.php.net/rfc?do=register OK. I tried to do this. I got an account (username:isfs), but it seems it is nothing more than an unprivileged account--I don't seem to be able to edit or add pages at all. What do I need to do to be granted some? Greetings Ben, You now have rights to the wiki rfc namespace. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Sorry for moving offtopic, but if the PHP syntax is going to change then we should revisit other proposals that add/change syntax. For example, I think the short syntax for arrays was declined [from 5.3] mainly because it introduced a new syntax at a time we wanted to preserve BC: - http://wiki.php.net/rfc/shortsyntaxforarrays Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. The main reasons we moved to SVN and not Git include: - Less of a learning curve, because SVN is like CVS - Most of the CVS-SVN work was already finished - A few old timers didn't want us using Git - We aren't sure how the authentication/karma system would work Most people wanted (and still want) to move to Git, but moving to SVN was a simpler process. Any proposal towards Git should include how it'd work. Also, Github (yes or no) is another part of this. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Nov 19, 2010, at 6:45 PM, Stanley Sufficool wrote: On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor dani...@analysisandsolutions.com wrote: On Fri, Nov 19, 2010 at 04:41:48PM +0100, Ferenc Kovacs wrote: you can get pwn3d with magic_quotes_gpc = On That goes without saying. None the less, it will be problematic for PHP to disable/remove a security feature that some people rely on. Well then +1 for making the setting throw depreciated PHP startup notifications when turned on with a link to suggested security practices for SQL, exec(), passthru(), and other sensitive functions benefiting from magic quotes. Linking to a document sounds reasonable, but we already provide an E_DEPRECATED error when any magic quotes setting is enabled (as of 5.3.0), so the probable question here is if we should disable MQ by default (in 5.4) and remove it later (5.5 or 6.0), or simply remove it now. I lean towards disabling by default in 5.4, and removing in 6.0. Also throw an E_NOTICE depreciated for the magic_quotes_gpc() function as well for those that check if this setting is on/off. Punishing people who write compatible code feels wrong, so get_magic_quotes_gpc() should never emit an error. Heck, this harmless function might even exist in PHP 7. My guess is most people simply run stripslashes() if On, rather than avoid superior escaping mechanisms. But please start the movement in the direction that this will be removed in the future. I\'m having a difficult time grasping the exact implications here, except that a default value change mostly affects people without php.ini files. I\'m not sure who those people are, or how they may end up using PHP 5.4, but maybe a wiser old timer can predict this story. But for good measure: What we have already done with magic_quotes_gpc: --- (Note: sister magic_quotes_runtime has always defaulted to Off) PHP 4, 5.0, 5.1, 5.2 - Default (On) - php.ini-dist (On) - php.ini-recommended (Off) PHP 5.3 - Default (On) - php.ini-development (Off) - php.ini-production (Off) - E_DEPRECATED error when On Distributions/vendors: - I\'m not sure which defaults they all use We\'ve recommended Off for a long time now (year ~2000) so should feel okay with whatever decision is made. But, our main focus is handling clueless code that magically works (sort of) thanks to magical quotes. Magic! Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
What are your inputs on this matter? I'm struggling with this topic. We must do something, but it's important to understand that plenty of people unknowingly rely upon this security feature that's still enabled by default. Granted 5.3 does generate E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP version of errors enough to go from on to gone? So while those in the know (e.g., people who follow this list) find them annoying and wish they never existed, what are the implications? I'm still unsure how best to handle this situation but wanted to express these feelings now. Whatever the case, the education effort towards data filtering and sanitization requires a lot of improvement. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Nov 17, 2010, at 9:40 PM, Larry Garfield wrote: On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote: What are your inputs on this matter? I'm struggling with this topic. We must do something, but it's important to understand that plenty of people unknowingly rely upon this security feature that's still enabled by default. Granted 5.3 does generate E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP version of errors enough to go from on to gone? So while those in the know (e.g., people who follow this list) find them annoying and wish they never existed, what are the implications? I'm still unsure how best to handle this situation but wanted to express these feelings now. Whatever the case, the education effort towards data filtering and sanitization requires a lot of improvement. Regards, Philip I won't miss magic quotes if they're removed, but I can see the argument for saying not quite yet. Off-by-default is absolutely necessary if they're kept. (Dear god, you mean they aren't off by default already?) --Larry Garfield This is true. And in addition to the E_DEPRECATED error, it's worth mentioning that 5.3 includes two optional php.ini-* files (php.ini-production and php.ini-development) that disable magic quotes. But of course not everyone uses these, and default is how PHP behaves without a php.ini file. Older versions of PHP include php.ini-dist (On) and php.ini-recommended (Off). Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
On Nov 11, 2010, at 9:26 AM, Jonah H. Harris wrote: On Thu, Nov 11, 2010 at 12:22 PM, Will Fitch will.fi...@quepasacorp.comwrote: +1 here. Just want to make sure the RFC is written and discussed before the patch is submitted. I just registered for Wiki access and am waiting for the account to be approved. As soon as it is, I'll submit the RFC. Done, you now access to the RFC namespace. Have fun :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
