To paraphrase Marco Tabini if you work with PHP you must be doing so in a pretty deep cave to have not heard of HipHop for PHP and the fervor around it the prior to its official announcement this morning by Facebook.

I had a fortune to be part of the small group of PHP community people who were invited to take a peak at its technology prior to its official release in January. And I must admit it had been quite amusing to read some of the conjectures people were making about what it actually, given how off the mark most of their guesses were.

So what is HipHop?

In the tersest of terms HipHop is a tool that converts PHP code into C++ code that when combined with a PHP compatible engine and extensions (ports of some native PHP extensions Facebook uses) library also written in C++ can be compiled using GCC into a binary. This binary can then be ran on a command line or as a web server daemon that utilizes libevent. According to Facebook this can speed up applications by up to 50%, which is a pretty impressive improvement.

It is not entirely surprising that world's largest PHP deployment, such as Facebook would look at solution that would allow them to halve their not inconsiderable count of servers or double capacity. Releasing this solution as Open Source is I think a great idea, and big kudos to Facebook for doing so.

From a technical perspective the PHP optimization approach of converting PHP into a compiled language is not a completely new one, Roadsend compiler, a commercial product has been around for a few years now and has been doing that with some degree of success. That said it is not a trivial task and from an engineering perspective presents a fairly tricky development challenge, especially when you want to allow regular, off-the-self scripts to work. Perhaps more importantly, HipHop not a theoretical solution, "for you to test", it actually works, with most of the Facebook's servers running it and doing it well, on millions of lines of converted PHP code on daily basis, very impressive.

At this point you are probably thinking, that if it is so great and it works, I'll deploy it on my servers as soon as I can get my hands on the source code. Well, unfortunately things are not quite so simple, there are few technical and deployment challenges you need to overcome.
Continue reading "My Thoughts on HipHop "

I will be speaking again this year at PHP Quebec conference, which has now been renamed to Confoo and covers many more topics then just PHP, which should make things even more interesting. With over 100 talks things looks to be an amazing conference, my own talk with cover PHP 5.3 awesomeness

If you are using PHP, chances are that at some point you needed to serialize PHP data, whether it was transparently done for you inside the PHP's session handler or directly so that complex PHP data types (objects & arrays) could be stored in DB or files, most people have done this.

The default way of doing it is via a native PHP serializer, which creates a clear-text version of the data, which if you are serializing a fair bit of information ends up being rather verbose (read: BIG). This means that you end up having to store more data in memory, read more data from disk, etc... all of which slow down your application. As I was reading docs on Andrei's new memcache extension (memcached) I came across a binary serialization extension called Igbinary written by Sulake Dynamoid Oy. This extension promised much more optimal serialization routines by using binary, rather then a clear text format. Sounded, good so I decided to run a few benchmarks on it.

Continue reading "Igbinary, The great serializer"

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.

I was buying 2 monitors for the office today, when a came to paying the bill I discovered a rather nasty surprise. It seems that the Ontario government has decided to apply a $12.03 per monitor recycling tax as part of their EOS program. It looks like our liberal provincial government is always on a look out to grab more of our money, so they can spend it on idiotic initiatives such as eHealth.

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!