Become a Patron!

My Amazon wishlist can be found here.

Life Line

PHP Look Back 2005

Update : some of the links were pointing to a wrong URL.

Welcome to the fourth installment of the PHP Look Back. Just as in previous years, we'll look back on PHP development discussions, bloopers and accomplishments of the last year. This is not supposed to be a fully objective review of last year--note that the opinions in this article are that of the author, and not of the PHP development team.

January was a quiet month, with not much going on. After about 8 months , we finally added a PIC/non-PIC detection mechanism to the configure script, that will select non-PIC object generation for supported platforms (Linux and FreeBSD). Non-PIC code is about 30% faster, as measured in earlier benchmarks. A week later, Leonardo was wondering whether we planned on adding type hints for scalar types to PHP. As PHP is a weakly-typed language, this is not something we wanted to add, although we did add support for an "array" type hint, later in the year. With PHP 5.1's new GOTO execution method (added last August), variable name lookups are cached internally. This caused some problems for Xdebug , as it needs some information to find out which variables are used in a specific scope. Andi committed a patch that made this possible, again. Michael started working on his HTTP extension (which generates way too many commit mails ;-) and encountered a problem with a naming clash between PEAR's HTTP class and his PECL extension. Greg responded and said that this problem will be solved when PEAR 1.4 comes out, with its channel support.

Andi started discussions in February by pointing out a date for the first beta of PHP 5.1: March 1st. He declared that "both PDO and Date should be included in the default distro" and others suggested that XML Reader should be included by default, as well. In reply to Andi, Rasmus mentioned that he would like to see the filter extension included as well. The discussion about this extension quickly transitioned to data mangling of input request variables that would not be influencable by the script authors, but only by the system administrator. In the end, this discussion made place for the topic of Operator overloading , where certain people kept reiterating that operator overloading is a good thing . Andrei tried to stop this discussion by being funny , but that didn't work very well . Around the same time, Wez announced the first beta of PDO--PHP Data Objects. Wez wanted people to test PDO, and of course, over the next couple of months, there were various PDO-related concerns and issues raised. Another discussion in January was about auto boxing in PHP. Auto boxing is the encapsulation of all primitive types as objects. Naturally, people asked WHY we would want to have this, and no sound reason was given. In the end, this discussion suggested that phpDocumentor should handle type determining, instead. Having a doc block parsing extension to the reflection API would be nice, although a bit hard. We also had an often-recurring discussion on why GPL is a bad idea for PECL extensions. John added the first version of XMLRPCi to CVS; why he chose this silly name is still unknown. Jani wrote about a problem with overwriting globals , an issue that--later in the year--warranted a new PHP release, and Greg introduced PEAR 1.4, with channel support. Halfway through the month, Marcus mentioned a few things that should go into PHP 5.1; most notably the __toString() fix, which unfortunately, did not actually make it into the release. Type hinting with = NULL did make it in though. Martin Sarsale reported an issue with references and segfaults, something which had been annoying us for quite some time, too. This issue got fixed in PHP 4.4, albeit not without a little bickering. (More about that later.)

In March , Ilia proposed a patch that adds a special token that tells PHP's parser to abort parsing when the token is encountered. This allows us to attach binary data to the end of a PHP script. This is highly useful for one-script installers, such as the one that FUDForum uses. On the 14th of the month, Zeev released the first RCs of both 5.0.4 and 4.3.11. We also encountered further reference issues . The same guy that mailed tons of "fixes" to the internals list last June , was back with more patches. Andrei, once again, pointed out that it is a good idea to check with an extension's maintainer before applying patches, and Greg published the package2.xml documentation. Lukas, once more, pointed out the weird naming scheme that new extensions seem to be getting, and luckily Debian's PHP packages got rid of some of the insanity that was present in previous releases by not always building in ZTS mode. Unfortunately, their packages still force PIC mode for the libraries. A user brought up the idea of an upload meter patch again, and although we all seemed to remember that the original patch was rejected , no one could find the original thread where this was discussed. Last year's Look Back discussed this too, and there, the reason was mentioned . In the last week of the month, we had some fuss about "FreeBSD doing stupid things" regarding their naming of auto tools executables .

April started with a suggestion by Zeev to change the way that __autoload() works, by allowing multiple instances of this magic function. In the end we, didn't end up implementing this, and as Lukas describes , "Frameworks should provide __autoload() helper methods, but should never implement the function itself. Its up to the end user to do this." (This is exactly how we implemented it for the eZ components ). Andi wanted to release PHP 5.1 Beta 1 really soon, but as Jani mentioned , there where quite a few things that were still not fully ready, and thus the suggestion to call it "Alpha" was made, instead. During the thread some pet-features where brought up . Kamesh from the Netware porting team, found another reference issue . Marcus added File class to his SPL extension, causing a small stir--the new class clashed with applications that already define a File class. Although this is a valid point, projects defining a "File" class should know better and always prefix their class names. This same issue will pop up later in the year. A last, somewhat larger, discussion erupted when a question about whether APC could be used as a content cache was posted to the list. Rasmus found it an interesting idea , although this functionality can also be accomplished in user space. In the last point of the thread, Rasmus mentioned that APC will soon support PHP 5.

May had a slow start, and things only got interesting at the end of the month. The first thing that came up was Ilia's removal of dangling commas from enums, something that "was in c language from the first day" . Apparently, GCC 4 is "becoming worse and worse" , but luckily we can still just ignore the warnings . After a small private discussion with Dmitry about Marcus' and my reference fix patch , he came to the conclusion that this patch breaks binary compatibility and that this problem doesn't warrant a PHP 4.4 release. As this reference problem has been affecting many users, and definitely us over the past months, I wrote an email to the list stating that it is "totally irresponsible" not to release a fix for such a grave bug. Zeev also said that "we should probably not fix this at all in the 4.x tree" because of the hassles that accompany "breaking module binary compatibility". He also seemed to think that the bug can easily be worked around. Other users were a bit happier that we finally nailed this bug, and Jani replied to Zeev that the magnitude of this bug is pretty damn high . Rasmus added that he "will be deploying the patch and happily breaking binary compatibility" as soon as the patch is ready. Breaking binary compatibility is only a "burden on the maintainers of these packages" (of the various distributions). Wez thought that "the only logical move forward is a 4.4 branch and release" . In the end the Zeev almighty was "tired of going through the reasons again and again" and noted that "everyone appears to prefer the upsides to the downsides". This resulted in the creation of the PHP_4_4 branch in the first week of June .

Wez added a new patch to our CVS server that allows us to block access to specific branches--with this, we closed the PHP_4_3 branch for good. A week later, I announced 4.4.0RC1 which features the reference bug fix. Andi wrote another PHP 5.1 mail , which spawned a nice long discussion on adding goto to PHP and comparing goto to exceptions. Magnus smartly added that "people are talking about hypothetical messy code because of goto" and that they forget that you don't have to use a language construct if it is available. The same thread also went into a branch that discussed the ifsetor() language construct. After Andi returned, he decided not to do anything with goto or ifsetor , and that it was now the time to branch, so that we can merge the Unicode support that was developed in parallel by mostly Andrei and Dmitry, although Rasmus is "pretty sure the current discussions will pale in comparison to the chaos that will be created when the Unicode stuff goes into HEAD!" Johannes wondered when the new date stuff was going in; it was added a week later, just before PHP 5.1 beta 2. Lukas suggested that we add the public keyword to PHP 4.4 for forward compatibility. Rasmus again wondered about "the reasoning ... for not having var be a synonym for public in PHP5" . Andi mentioned that this "was meant to help people find vars so that they can be explicit about the access modifiers" when moving to PHP 5. A few days later, Andi read a blog posting which described how PHP 4.4 is breaking backwards compatibility by issuing an E_STRICT in cases where you abuse return-by-reference. This, however, was not actually the case . Yasuo started a long thread on allow_url_fopen() and claimed it was dangerous . The main result of this thread seemed to be that we wanted to split the setting into two different ones: one for allowing remote opening of URLs and one on including remote URLs. However, this is something we could not yet change. The last thread of the month was by Andi, writing about the PHP 5.1 release process .

In July , Jessie suggested a String extension that declares only one class: String. This class is meant to prevent copying of the string's data for most operations (which is currently done with PHP's string functions). Most of the other developers where against it for different reasons: "String is such a generic name for a non-core class" and "the savings gained by this will be more than offset by OO overhead" , so we will not let "this get anywhere near the core" . In the same week, I made more changes to the date extension that allow users to more easily select the timezone that they want, instead of having to rely on the TZ environment variable. This is also needed because the TZ environment variable can most likely not be used in a thread safe way, and it is certainly not portable . Also in the same week, I proposed an API for new Date and Timezone functionality . After some pressure , I added an OO API, too. Near the end of the month, I committed the implementation of the new date functionality . It was, however, #ifdef-ed out to facilitate discussions at a later date. Jessie came up with Yet Another Namespace Proposal , and tried to come up with a solution for all the previous problems we had with the implementation. He also made several patches that added namespaces to PHP. We had some more fuss about PHP 4.4 breaking BC, where some people didn't see why we had to do this fix. Unfortunately, there were some quirks that we still had to sort out. In this same month, Rasmus released APC 3.0.0 which came with PHP 5.1 support and numerous fixes.

August was the month of PHP 5.1 RC 1. It started with a discussion on instanceof being "broken," as it raises a fatal error in the case where the class that is being checked for doesn't exist. Andi declared "if you're referencing classes/exceptions in your code that don't exist, then something is very bogus with your code" and "the only problem is if the class does not exist in your code base, in which case, your application should blow up!" I raised a question about whether the new PHP with Unicode should be called PHP 5.5 or PHP 6.0 . As most of us, Andi wants to go "with PHP 6 and aim to release it before Perl 6" . After PHP_5_1 was branched, Andrei merged the Unicode branch and gave us some instructions on how to get going with it. He also introduced the general ideas behind the implementation . RC1 was finally rolled, about half way through the month, followed by PHP 5.0.5 RC2 a week later. During the development of the eZ components we discovered various things in PHP OO's model that we wanted to see changed. One of those issues was described in the Property Overloading RFC . Unfortunately, not everybody could be convinced , and no changes where made. I will try again though :). The other issue that we raised was that failed typehints throw a fatal error , while that is not strictly necessary. Instead of throwing exceptions in this case, the discussion turned towards adding a new error mode ( E_RECOVERABLE ) that will be used for non-engine-corrupting fatal errors at the language level--this is exactly the case with failed typehints. The longest thread of the month however, was started by Rasmus when he posted his PHP 6 wish list which featured controversial changes such as "removing magic_quotes" and "making identifiers case-sensitive", to which most developers quickly agreed . Following his initial wish list, the crowd went wild and started suggesting all kinds of weird changes, such as "Radically change all of the operator syntaxes" , adding "<?php6" as a BC breaking mode, and "Named parameters" . Marcus made a list of his own which would later become the first draft of the meeting agenda for a PHP Developers Meeting.

In September , Antony committed an upgraded OCI8 extension which fixes a lot of bugs . We also decided to play a bit nicer with version_compare(), regarding naming release candidates. Zeev wanted to roll PHP 5.0.5 but there was an issue with the shutdown order. The reference issues ( 1 , 2 ) returned too. The first one turned out to be an incorrect merge to the PHP 5.0 branch, where suddenly some of the notices turned into errors . The second one is simply a small change in behaviour which previously created memory corruption. Rasmus explained the issue a bit more , once again. Ilia tried to implement a clever fix which turned out to be a problem later on. Pierre started a discussion on supporting Unicode in identifiers, something he didn't want to see. PHP already supports using UTF-8 encoded characters in identifiers, so removing this feature will break BC unnecessarily. Besides breaking BC, many people simply want to use their own language for writing code, as Tex writes. Zeev had another attempt at PHP 5.1.0 RC2 with the latest PEAR being the only thing missing. Marcus brought up the issue of __toString() again, and finally managed to get it into CVS, but unfortunately not in time for PHP 5.1. Stanislav noticed some problems with detecting time zones, as the new date/time code did not try to attempt detection in favour of the new date.timezone setting . After some discussion, we came up with a solution , which was then implemented. It should guess the timezone correctly in most cases, even on Windows. I also added support for an external timezone database .

In October , I noticed some weird notices with "make install-pear", without a clue as to why they were showing up. This discussion turned into a why does PEAR not support PHP 5.1 thread. In the end, Greg managed to nail down the weird notices though. I also noticed a commit by Dmitry that ignores "&" when $this is passed. I pointed out that this should not be supported (in PHP 5), as it doesn't make really sense that people won't see a warning/notice/error when they're doing something silly. Dmitry explained that disallowing it would break code, but he also writes that by "using '=& $this' a user can break the $this value"--which is something we definitely should prevent. He suggested we make this an E_STRICT warning, and Andi suggested we escalate this to an E_ERROR in PHP 6, but neither of those things happened. A week later Piotr was asking for a tarball of our CVS to make it "possible to convert it to Subversion repository ... so browsing the repositories would be much easier". We were wondering why he needed that, as we offer our own browser already. Matthias said that we "do not want to set off yet another discussion about the changes 4.4 brought", but that is exactly what he did. Again, there is something wrong with his code, and thus the warning is legal. After resolving the timezone issues last month, we were surprised by a message from Zeev. He simply missed the conclusion in the "lengthly thread". After the negative comments on the PHP 4.4.0 release, Lukas, Ilia and I set up a routine for involving some of the more known projects to the PHP 4 and PHP 5 release processes. As part of this effort, we send out a mail to all participating projects whenever we have a release candidate to test. I raised some concern regarding our current Unicode implementation because of maintenance issues. In part of my mail, I also indicated that I wanted "to clean up PHP 6 for real" , after private discussions with Marcus and Ilia. Behind the scenes, we prepared some material to organise a PHP Developers Meeting to discuss the Unicode implementation and the extended "PHP 6 Wishlist". I also committed a patch that allows typehints for classes to work with = NULL . Another guy raised the issue of "that new isset() like language construct" , but this ended up going nowhere as people were suggesting very Perl-like operators. Jani replied to this thread with "How about a good ol' beating with a large trout?" On the last day of the month, we released PHP 4.4.1 which addresses some of the reference issues we've seen in PHP 4.4.0.

In November , we prepared to finally release PHP 5.1, and one of the efforts was to make an upgrade guide for people switching to PHP 5.1. Sean noticed a problem with the parameter parsing API's automatic type conversion. Like Andrei , many people think that "passing '123abc' and having it interpreted as 123" is still wrong. Dmitry implemented support for "= null" as default to array type hinting, something that I did not do on purpose because "= array()" is the logically correct way of doing this. Andi agreed with me on this. Ilia implemented, in PHP 5.1RC5 , one of the items that was on the outcome list of the PHP Developers Meeting: adding a notice that warns people that curly braces for addressing a character in a string is now deprecated in favour of the [] operator--contrary to the current explanation in our manual. {} and [] are exactly the same thing and "having two constructs for the same behaviour is silly and leads to confusing, hard to read code". The outcome of this discussion was the removal of the notice in PHP 5.1 and the likely conclusion is that it is not going to get removed. Another change that was made PHP 5.1RC6 was the creation of the "Date" class, which caused quite a stir after the release of PHP 5.1 . The reason to introduce it in 5.1 was simply to make sure that no applications were going to break if we introduced the Date class later in the 5.1.x series. Unfortunately a lot of projects, including PEAR, never heard of "prefixing" class names, causing class name clashes. Marcus describes the problem as "PEAR ignores coding standards" , but others suggested that we rename the internal class to something silly like php_date. Andrei asked "what does renaming really buy us? The only purpose of introducing this class in RC6, as far as I can tell, was to reserve the 'Date' name for future use." Now that we know about this issue, it's time for PEAR to start prefixing its classes, so that we finally can do the right thing and add our Date (and Timezone) classes, code that has been around for months now, and I'm quite tired of waiting for it to be in a release where I can use it. We ended up reverting the change that claimed the Date and Timezone classes, and released 5.1.1 with this change. After the PDM I posted the meeting notes to the list. Most of the outcome was well appreciated, except the curly braces idea which had already been discussed. With these notes, we hope to make PHP 6 a success. The notes also spawned numerous polls on the symbol to use for separating namespaces from class names/function names. We also discussed our version of a goto: labelled breaks . The filter extension , which I've been developing for quite some time, did not make it into PHP 5.1, although it is a good idea to add it, now, with an "experimental" status, so that this wanted extension gets more testing. Perhaps for PHP 5.1.2...

December was a quiet month with not too many things going on. Ilia proposed a plan for PHP 5.1.2 and released PHP 5.1.2RC1 , Zeev committed Dmitry's re-implementation of the FastCGI API and some user was whining about our "official" IRC channel (which doesn't exist).

That was it for 2005! I hope you enjoyed reading this, and have a happy new year. Extra thanks go to Ilia, for being release master, Dmitry for maintaining the engine, Jani for hunting down bug reports, Andrei for his work on Unicode, Mike for his enormous stream of useless commit messages ;-), and to all others who made PHP happen this year.


This article has a short URL available:


Derick, thank you for yet another great "PHP Look Back".

Thanks for the great summary. Happy new year to the PHP development team and all PHP users around the globe!

Derick, a big thanks for taking the time to summarize what was a very active year for PHP community.

Wow, that must have been really a lot of work, and indeed it's great! Thanks a lot! A happy new year to all those PHP people ot there!

Great summary Derick, I hope PHP is doing better and better. See you in your 2006 summary ;)

Add Comment


Will not be posted. Please leave empty instead of filling in garbage though!

Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.

All comments are moderated