The issue Derick pointed out:

In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working.

Greg's patch makes it possible to "override" the internal class if need be, making it so that code currently working wouldn't break. All it takes is to "use" is like you normally would and and the magic happens behind the scenes.

I was wondering today why use mbstring rather than iconv in Dokeos, and honestly I didn't remember exactly why I had chosen mbstring in the past, but finding information about the *differences* between the two. [...] Searching a bit more, I found a PPT presentation from Carlos Hoyos on Google.

Essentially, it boils down to how the library is integrated - mbstring is bundled and iconv is pulled from an external source. So, if you're looking for maximum portability, he recommends mbstring.

If you try to get informations about parameters from methods of internal classes - forget that. Examining several internal classes my key findings are: either there is no information about parameters available and the reflection API says the method does not have any parameters, or the information about the parameter is wrong.

He includes code examples along side the output from the script to illustrate his point.

he bad news: mysqlnd might have bugs. How to report and debug these bugs - using mysqli_debug() - is subject of this posting.

They step you through the process for finding out what's causing the problems (internal versus external debugging) and how to make client traces with the mysqi extension to make it even easier for the developers to track down the problem. They also suggest a few things to send along with your bug report - like the PHP code calling it or the SQL you're using to select/update/insert/delete the data from your database.

I spoke with him on some of the things that had lead up to making this decision and he mentioned it as a two-fold reason: one was some personal conflict between other PEAR developers and himself and the other an issue of time and interest in the project. He still wants to see it succeed, but just doesn't see the time in his life right now to do his part. Pierre will continue to work with the PECL extensions and on the PHP internals groups to help improve and develope them towards future versions. Some of the extensions he lists as the ones currently in his development are things like GD, xmlwriter, Zip (of course), and filter.

It is just a normal process, things and people change. I would have preferred a slower switch, as I was working on my leave (giving lead for many of my packages to other friends).

Pierre's PEAR work can be seen on this page of his blog and includes all of his PEAR and PECL work as well as PHP internals and Pimp/Cairo/GD development work.

You can also check out the decision in his own words over on his blog.

Recently, some code in the PEAR installer was discovered to be invalid in PHP 4. After a bit of investigation, I realized that the significant difference in the way objects are represented internally in PHP 5 was the culprit.

In PHP 5, this displays as bool(true), but in PHP 4, it displays bool(false). The reason is that in PHP 4, objects are simply glorified associative arrays, and so PHP treats the above [example] code exactly the same.

He strongly suggests that, to help with this issue, you always check to ensure (with is_object) that what you're passing is a true object.

He's made an update to the post since it was originally released, mentioning how some classes will also define their own cast handlers.]]> Mon, 27 Mar 2006 07:05:53 -0600