[PHP-DEV] Re: Bug 61272
On 26 November 2012 15:46, Casper Langemeijer langemei...@php.net wrote: Hmm.. I suppose It's up to me to make a strong (if possible watertight) plea for the old way. I will try: 1. I don't think my patch impacts the efficiency of php_output_clean(). It adds a single if with a binary compare. True: this causes output to get piped through the output handler, but the output handler callback function could be smart enough to back off when the PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback. 2. Current behaviour is *not* according the documentation. ob_start() documentation states: An optional output_callback function may be specified. This function takes a string as a parameter and should return a string. The function will be called when the output buffer is flushed (sent) or **cleaned** (with ob_flush(), ob_clean() or similar function) or when the output buffer is flushed to the browser at the end of the request. When output_callback is called, it will receive the contents of the output buffer as its parameter and is expected to return a new output buffer as a result, which will be sent to the browser. (*-emphasis mine) Which emphasizes the fact, that implementation and documentation differed quite a bit. The ob_clean note was obviously added in 2008 [1] [2], when the new output code was sleeping in the PHP6 branch. Current behaviour differs: On calling ob_end_clean() or ob_clean(), output_callback is called, but *without* the contents of the output buffer as its parameter. 3. Implementing my patch will never break anything. The output will be passed to the callback, but anything returned by it *will* be discarded. 4. If you are not going to pass the contents of the output buffer on ob_end_clean() or ob_clean() to the callback function, Why would you call the callback anyway? I guess I got your argument now :) I'll have a look. Thanks for spending your time to make PHP better. [1] http://svn.php.net/viewvc/phpdoc/en/trunk/reference/outcontrol/functions/ob-start.xml?r1=246628r2=268496 [2] https://bugs.php.net/bug.php?id=44150 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup
Good idea! Am 26.11.2012 um 22:21 schrieb Sara Golemon poll...@php.net: https://wiki.php.net/rfc/request-tempnam Just a bit of hand-holding for those who don't remember to clean up their messes. -- 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
Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup
On Mon, Nov 26, 2012 at 4:21 PM, Sara Golemon poll...@php.net wrote: https://wiki.php.net/rfc/request-tempnam Just a bit of hand-holding for those who don't remember to clean up their messes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php While I don't think there's anything wrong with this feature, I'm also wondering if maybe people that need this should be using tmpfile() instead? I understand they do slightly different things (in that one gives you an actual file name the other gives you a file handle), but I normally don't need or care about the file name if I expect my temporary file to live and die with the request. Things I usually use tempnam() for are usually things that get born with the request and don't necessarily die with it, like binary storage that's tied to the session (temporary file uploads that might be moved later or deleted). But I don't see any harm in adding this either.
[PHP-DEV] [VOTE] ext/mysql deprecation in 5.5
All, I've moved the ext/mysql deprecation RFC into the voting phase. You can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as discussed last week, there are two questions: the first being a simple yes/no question (which will determine whether the RFC is accepted or rejected), and the second to clarify what the preferred course of action will be if the RFC is declined. Please vote on both, unless you particularly wish to abstain from one of the questions. I've also updated the RFC slightly, but not in a way that changes what's actually proposed: Ulf noted that he wasn't comfortable with having the Oracle Wiki link there for converting to MySQLi, so I've replaced that link with another, more recent tutorial (albeit PDO only) and added a link to Ulf's recent blog post about the benefits of mysqli and PDO over ext/mysql. This is mostly useful for documentation purposes, since I think there's general agreement that we should have more resources covering upgrading to newer extensions regardless of the outcome of this RFC. At this stage, I intend to close the vote in a week's time: so Wednesday, December 5. Thanks, Adam, who knows he's a little late with this, but being sick sucks. Sorry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5
On 28 November 2012 14:03, Adam Harvey ahar...@php.net wrote: big snip, voting open, et cetera OK, so the first e-mail was the official announcement of voting being open. I'd now like to quickly lay out why I voted yes, and why I think it's the right way forward. Feel free to hit next if your mind is already made up. :) Ulf produced a blackly entertaining timeline of MySQL support in PHP in one of the earlier RFC threads[0]. We've had better options than ext/mysql available in mainline, stable releases since 2004, yet it's taken a long time for there to be a serious push to encourage users to use the newer extensions. There are both a carrot and a stick here. The carrot is well laid out by Ulf in his blog post[1] — the newer extensions are more featureful, faster, and in the case of PDO particularly, easier to use (and harder to misuse). The stick is that we have this faintly ridiculous situation where we have four extensions in php-src for accessing one DBMS, one of which (ext/mysql) is barely maintained and has an API that encourages poor programming practice. Deprecating ext/mysql in PHP 5.5 doesn't mean it's going away immediately. It doesn't even mean it's going away next year: there's no reason at all we can't keep ext/mysql deprecated for more than one release branch. In fact, that would be my preference. As others have said: ext/mysql is a hugely used, popular extension. We can't rip it out overnight, and nor should we. Deprecation is a strong signal. It's a signal that it's time to update tutorials. It's a signal to schedule upgrades for code when new versions are written to use more modern APIs. It's a signal to those of us who speak at conferences, and help people in various fora and various ways that we should redouble our efforts to communicate the benefits of MySQLi and/or PDO. Most of all, it's a signal that we're serious about improving PHP and encouraging our users to improve their own code with us. Thanks for reading. If you got this far, I'll buy you the beer or non-alcoholic substitute of your choice at any conference I'm at next year. (Which, since I'm moving to Vancouver in the new year, may actually be a few.) Adam [0] http://news.php.net/php.internals/63982 [1] http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
