PHP

The slides from my talk, introducing PHP 5.3 are now up and can be found here:
Slides

It has been a rather crazy last two weeks at work, so I didn't get a chance to revisit the type hinting matter. Unfortunately, while initial outpouring of support for inclusion of type hinting into PHP 5.3 and 6 was substantial, it all kinda petered out once more people started voting. To be specific, there is a large amount of support for the feature in general, but very few people seem to think it should go into 5.3.

I feel that 5.3 is the only release that would make this feature usable, since that is the version of PHP I could see myself using at work in a near future as well as a release other people would be using for the next few years, at least. PHP 6 is just very far a way from any sort of a release, let alone a production worthy version and at the same time there is no tentative agreement on making 5.4 in the near future. If it went to 5.3, which would be "work worthy" I could justify spending the time to maintain the patch across all branches, but with PHP 6 only, it is simply too impractical.

That said, at work we will transition to 5.3 soon, probably around 5.3.2/3 time, so I do need a type hinting patch. To that effect I've cleaned up and improved the old patch based on comments from various people, notably Stas and Dmitry (thank guys) and made a copy that I intend to use for work.

The patch is now pure type hinting, no more virtual types like SCALAR and NUMERIC, it also does not offer any type casting support. Basically its just a type hinting patch, with full reflection support. Since the last iteration of the patch the following improvements have been made:

1) Modify the parser to not reserve string/integer/etc... keywords used for type hinting. Won't break code that uses "class string", etc...
2) Added getTypeHint() reflection method to determine the type of hint a parameter has
3) Revised the parser (thanks Stas) to properly parse out type hints.

The patch can be found here: http://ilia.ws/patch/type_hint_final.txt
and the test suit here: http://ilia.ws/patch/type_hint_tests.tar.bz2

Update July 22, 2009

A bug was found by Gwynne, which prevented constants (other then NULL) from being used as default values of type hints, she was also kind enough to provide the patch for the problem. The patch was updated with this fix and an additional test was added for this eventuality. Thanks Gwynne!

There has been a lot of comments both on this blog and the internals list. There seems to be a fairly large group of core developers who like the idea as well as surpassingly large support base on the user level too (wow, didn't think that this many people want type hinting). Unfortunately, there have also been, as is typically on the internals list a few people complaining for the sake of complaining. Their arguments have ranged from type hinting is against PHP's loosely typed nature and people will mis-use it and make PHP into something that it is not, to I don't need or will use it, so no one should get it.

That said these people are in the minority, albeit a rather vocal one, so progress is being made. There have also been a number of really good suggestions by folks who have reviewed the patch (big thanks guys) and their improvements have been incorporated into the version 2 of the patch. Here is the quick changelog.

1) Added support for "object" type hint
2) Modified the patch not to break binary compatibility so you can now use patched PHP without having to re-compile your extensions or having issues with binary ones.
3) Added full reflection support, which I appropriated from Felipe's earlier work on type hinting
4) Added support for type casting, where by you can do things like this function a((int)$foo), which will force PHP to cast the value of $foo to an integer
5) Added tests, which again I partially appropriated from Felipe's earlier work.

The updated patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt
The mini test suit which can also show practical examples & limitations of the functionality can be found here: http://ia.gd/patch/type_hint_tests.tar.bz2

I am posting it here for peer review and comment. If all goes well, I am going to post it to internals for a vote, which will hopefully pass. So, if you want the feature in, or you think its crap, watch internals on Monday so you can make your opinion known via a +/- vote.

For a few years now at work we've been using a patched version of PHP, one those patching featuring type hinting. Over time this proved to be a very handy feature that allows for a much more readable code and introduces a language based validation layer to ensure that the right data types are getting to your functions and methods. It also caught numerous bugs due to functions returning or passing un-expected values. Best of all this feature does not require any changes on the part of opcode caches (essential component for PHP performance) and allows for simple deployment.

I and other people have tried a number of times in the past to introduce type hinting into stock PHP, but unfortunately have never been successful. On a general level most people agree it would be a good idea to have, since it is an optional feature and does not introduce any regressions, heck you can even mix type hinted code with the non-type hinted one. The "PROBLEM" has always been combining of PHP's typeless nature with type hinting, which is where the consensus has been difficult (impossible) to reach. To illustrate the problem let's consider the following:

function foo(int $bar) {}

Some people would expect that passing "1" (string containing number 1) would be accepted by function foo() and not raise any type errors, since in PHP typically, numbers within strings are considered to be perfectly valid numbers ("1" + "1" == 2). Hence the conflict, some people (I am a part of that group) think that type hinting should be strict, while others think it should be more permissive to be inline with PHP's fluid nature.

With introduction of PHP 5.3 and free day in the middle of the week (Happy Canada Day to all Canucks) I've decided to port my internal patch to 5.3 and introduce a new 'feature' to it to hopefully bridge the divide. I've added a IS_NUMERIC (numeric) type hint that allows the script author to designate a parameter as having to be number, meaning input of type boolean, long or float as well as strings containing purely numbers will be accepted. This means if were to rewrite my previous function as:

function foo(numeric $bar) {}

Then calling foo("112"); would perfectly valid. To further extend basic type hinting support I've also added IS_SCALAR (scalar) type hint that allows a parameter to be designated as scalar, which means it'll accept any boolean, float, string or integer value.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

I've also posted it to the internals list in the hope of gathering enough support on the part of PHP developers and users to have it added to 5.3 and future releases of PHP.

It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a complete RFC on type hinting with patches and even test.

After over 2 years in development, huge amount of commits and changes PHP 5.3.0 is finally out. Kudos to Lukas M. Smith and Johannes Schlüter who have managed this herculean task and overall have done an excellent job.

There are some really nifty features in this release such as namespaces, closures, mail() logging, a bunch of new extensions and much more. Hopefully, the process of making 5.3 be production ready will be a quick one, as a large amount of testing has already gone into making this release possible. In fact, I be brave enough to say that for non-mission critical environments PHP 5.3 is ready to go as is.

A few hours ago, 11th release of PHP 5.2, 5.2.10 was released to the world. This, as most past 5.2.X releases has been largely focused on bug fixing with quite a few obscure crashes and memory leaks being addressed, in addition to a single security fix in the exif_read_data() function. All in all there are over 100 individual bug fixes in this release and most 5.2.X and definitely all 4.X users should consider upgrading to this version.

The sources and windows binaries for this release can be found at http://www.php.net/downloads.php and the detailed changelog itemizing all of the changes can be seen here.

Wow, time certainly does fly.
I've started with PHP back in 1997, and A LOT has changed since then in terms of the language's capabilities, user base, and the sheer quantity of sites and applications built on it. Hopefully the next 14 years will bring as many improvements and innovations as the 1st 14 did. Happy B-Day PHP!

The first release candidate of PHP 5.2.10 was just released and is available for download at:
http://downloads.php.net/ilia/php-5.2.10RC1.tar.bz2 (md5sum: 4ef611fdcf7269b2d372dbdebc504cdb)
For windows users, the all manner of binary packages can be found at: http://windows.php.net/qa/

This is a stabilization release with a whole bunch of bug fixes and no new features, so I hope it'll get released quickly. You can help make it happen by testing your code against this RC and reporting any new bugs and/or regressions you come across.

The slides from my PHP Quebec talk on "Common Optimization Mistakes" are now up and can be downloaded from here:
http://ilia.ws/files/phpquebec_2009.pdf

I am pretty happy with the talk, which was a bit strange for me, since I get to talk about some of the downside of optimizations, rather then talking about the various specific optimizations. It looked like the audience liked the talk (I hope), so the results seems positive

After a fairly timely (by PHP standards) release cycle the 5.2.9 release is finally out. As usual there are a few security fixes and a fair number (about 50 or so) general bug fixes. All users are encouraged to upgrade to this release, especially so if you are using libxml 2.7 and XML extension, in which case you definitely want to upgrade since this release fixes a CDATA breakage.

Big thanks to all the people who contributed patches and fixes as well as those who took the time to file detailed bug reports that helped issue resolution. We'll see how long it will take 5.2.10 to be released

The official release announcement can be found here and the full changelog is available here.