iBlog - Ilia Alshanetsky

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.

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!

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.

After reading about rev="canonical" and all the hoopla about domain shorteners, I've decided to see how short of a domain I could get for my blog to avoid having people needing to use things like tinyurl etc... to reduce the lengths of URLs. The goal was to get a 2 letter domain with a 2 letter extension, an easy solution seemed to be the .me extension (Montenegro), but alas I could not find a single registrar that would allow a 2 letter domain registration (ia or ai, my initials). It seems most registrars or resellers use generic libraries that no matter what disallow registration of domains <3 characters in length. The reason for this being that most (but not all) registries typically reserve 1 and 2 letter domains. So even when the domains are available, you cannot register them. Fortunately, after some whining on twitter, someone from iWantMyName did some targeted marketing at me . Their site allows you to search through about 5 pages of domain extensions, and for about 1/2 dozen domain extensions they do allow 2 letter registration.

The end result, I am now a happy owner of ia.gd (.gd being the extension for Grenada), it was not particularly cheap $49 as compared to GoDaddy where a common extension can be had for $7-$9 depending on a promotion at the time. However, GoDaddy's domain search system blocks 2 letter domains en-mass, even if they are allowed, so GoDaddy's #fail is iWantMyName #win.

A few days ago, Microsoft had done a low-key launch of IE8, which means you need to make your applications compatible with 3 differently broken version of IE ;-P. The biggest challenge IE8 poses is that it runs in "strict" mode by default, which coincidentally breaks all of the previous IE6/7 hacks that had to put in place to make CSS and Javascript render in IE the same way they do in other browsers.

Fortunately, unless you wish to refractor your entire code to support IE8 strictness, MS did add a "compatibility" switch, via the X-UA-Compatible meta-tag or header, if you change its value to "IE=EmulateIE7" it makes it emulate the "strict" mode ala IE7, which at least in all of our code makes it render things properly. However, there is a "slight" problem, which I discovered while trying to implement this function.

According to the docs, you can trigger this behavior via the following meta tag: , unfortunately it didn't work and according to the IE8's developer tool the default strict mode of IE8 was still being used. No matter the value, be it IE=IE7 or IE5 or EmulateIE7, it would just be ignored. Eventually, I realized that perhaps the DTD is the problem, our pages use XHTML/Transitional DTD, (), which means custom meta tags are effectively spec violations. Which, as far as I can tell IE8 in it's strict mode happily ignores, Catch 22!. This is despite a nice note inside MSDN Blog that says:


The solution, is to set the X-UA-Compatible value via an HTTP header ala:


This means the parameter is outside of HTML and will get properly captured by IE, in our case that solved all of the JS and CSS issues that appeared in IE8. For those of you using ExtJS date picker, this does solve the cut-off of the calendar window.

At the PHP Quebec conference I've succumbed to peer pressure and decided to sign-up for twitter. So, for those of you interested in following me (damn stalkers ) my twitter id is @iliaa