PHP 5.4 – looking back

With 5.6.0 having been released and 5.4 branch nearing its well-earned retirement in security-fixes-only status I decided to try and revive this blog. As the last post before the long hiatus was about the release of the 5.4, I think it makes sense to look back and see how 5.4 has been doing so far.


Release process. Combined with RFCs and git. It’s hard to believe we used not to have it. RFC process is working great, git makes all the processes tick and we have scheduled releases, working CI setup and much better predictability and management of releases overall. It’s no big deal unless you remember how it was before.

Built-in webserver. It really helps when you can just set up something browseable (is this a word? now it is) with PHP alone, without bothering with Apache setup and other moving parts. This is again a case of something that you don’t realize how much you missed it until you start using it.

$this support in closures. Having to write 5.3-compatible code for the last couple of years, I can’t emphasize enough how sorely it was missing in 5.3. I really regret the fact we could not get it into 5.3.

Syntax sugar like [] and <?= working everywhere. It’s a small thing but it adds up. I usually do not give much weight to saving couple of keystrokes and so on, but these to me really improve coder’s quality of life.

Removal of old “features” (since they ended up in the dump, is it right to call them features anymore?). Nobody is missing the safe mode or magic quotes or register_globals. Good riddance. Wish we parted ways sooner.


Traits. I must say I haven’t seen big adoption of the traits feature. Yes, of course people use it, there are tutorials, there are articles, etc. But at the same time compared to how much namespaces were needed or how much closures proved to be a great help, traits adoption, IMHO, remains lukewarm at best. To me, it has not lived yet up to its promise. Maybe I’m missing something, tell me if you have great examples there.

Adoption. This is a problem for new PHP versions and for developers of distributable PHP software – PHP versions are becoming “good enough” and people are reluctant to move forward, which also delays adoption of new features by library & packaged software writers. Look at the numbers: almost 3/4 of the PHP developers are using EOLed versions! 5.4 adoption is low at 22% and 5.5 adoption is abysmal. I hope that more streamlined release cycles and heightened attention to BC matters would bend this tendency. But so far it is not encouraging. WordPress numbers look even worse.

Don’t know

callable type. How wide is the usage? How useful it is in practice? Is it being used in major projects? I really don’t know.

Performance. It feels weird to put an obviously great improvement in this category. I would expect performance be a major driver for people to move forward, but the numbers suggest otherwise. As much as I love the performance improvements (a lot!), I really have no idea on how much it influenced the community and made them go to 5.4 (or beyond). Are there any surveys, links, studies, etc. in this regard? I see a lot of talk about performance but how many people also walk the walk? Are the numbers quoted above misleading?

mysqlnd. 5.4 is the first version where mysqlnd is the default mode of doing mysql. It has better performance, great features and I’ve been using it for years without a problem. But how widely it is adopted – do people still prefer the old way or love the new one? Do they use the plugin API widely?

Anything else?

Did I forget to mention something that really made your life better in 5.4? Did I conceal some flop that you wish we didn’t do? Please tell.

5.4 is out!

Since May 2011 we have worked on releasing PHP 5.4, and now it happened. Thanks everybody who helped with it!

PHP 5.4 has some new and exciting features – for some of them, like traits, I have no idea right now how they will work out and what people would do with them. It’d be very interesting to see.
For some of them, I feel they are basic common sense and long overdue in PHP (of course, not everybody may share my opinion 😉 – like [‘short’,’array’,’syntax’] or detaching <?= from INI settings. Some were just missing features that we didn’t catch up with before – more fluent syntax, linking objects to closures, etc.
Some things in PHP, as we have come to realize, were clearly mistakes – like register_globals, some were driven by real needs but proved to do more harm than good at the end – like magic quotes and “safe” mode – so we had to lay them to rest.

One of the best things that happened in 5.4 though is not immediately apparent. The engine behind 5.4 is significantly faster and consumes less memory than before. How much faster and how much less? Depends on your application, of course, but from some benchmarks 10-20% speed improvement and 20-30% memory improvement can be expected. Do your own benchmarks and blog about the results! Also would be a good time to ensure your application runs fine on 5.4 – since 5.4 is now the stable version and you have to start using it! 🙂

Another great things that happened – and is continuing to happen – is that we are finally moving towards more streamlined release process, towards having more regular releases (expect 5.4.1 release cycle to start in late March-early April and 5.4.1 be out in about a month after that) and more organized feature/change proposal process. There’s a wiki where people can post their RFC proposals, we have a voting process and while we may be still working out some fine details of the procedure, I feel we definitely have improved in this regard. It is time to get some organization into the process – we don’t need to create a bureaucracy, but some process is definitely needed and we’re establishing it.

Yet another thing that is happening – PHP project is slowly but surely moving from SVN to Git. This will be a great improvement. Having used Git for the last couple of years, I can clearly see that it can make many things we’re doing in PHP everyday so much easier. Can’t wait for it 🙂 Also makes easy for people to do pull requests and for core devs to merge them, among other things – should make bug resolutions, etc. work faster.

And after catching our breaths a bit and relaxing soon there will be time to think what we do in 5.5 – remember the thing about more regular releases? 🙂 I’ll try to post some thoughts about what I’d want in 5.5 soon.

ZF Oauth Provider

Zend Framework has pretty good OAuth consumer implementation. However, it has no support for implementing OAuth provider, and it turns out that there aren’t many other libraries for it. Most examples out there base on PECL oauth extension, which works just fine, with one caveat – you have to have this PECL extension installed, while ZF implementation does not require that.

So I went ahead and wrote some code that allows to easily add OAuth provider to your ZF-based or ZF-using application. That should make writing OAuth provider easier.

Note that the code does not implement the whole server – just the OAuth protocol wrapper, you’d still have to do all the work of managing tokens/keys/nonces by yourself. See example server in the repository and the wiki on github for more details on how to do it, but the protocol follows what PECL oauth does pretty closely, so many tutorials for it would be mostly applicable to this one too.

Check out Zend_Oauth_Provider on github, if you want to improve it – please fork and submit pull requests.



Being at OSCON, I’ve attended one good talk about Python oddities, which got me thinking about language syntax in general.

PHP is notorious among scripting languages for it’s verbose syntax – you have to spell out many things that are much shorter in other languages. Some people think it’s very bad that they can’t be “expressive”, meaning writing more clever code with less keystrokes. Sometimes they are right, sometimes they are not. Let’s consider two examples:

From PHP: 5.4 has a new array syntax: ['foo', 'bar'] which is the same as array('foo', bar').

I think it’s a good shortcut – because [] is a common expression for arrays (or structures that work like PHP arrays) in many languages, and it is obvious for most people how it works.

What’s an example a shortcut that isn’t good? Python (version 2) has this syntax for exception handling (this was one of the examples in the talk):

except Foo, Bar:

Now what this means: are we catching two exception types, Foo and Bar, or are we catching exception Foo and assigning it to Bar? The correct answer is the latter – it’s exception Foo assigned to Bar. I think it’s bad shortcut – because it uses a comma – which is common expression for lists and enumeration – to separate the type and the parameter. This leads to people writing things like “except KeyError, IndexError” which doesn’t do what one would expect to.

Pyhton people seem to agree with me, as in Python 3 the syntax has been changed to:

except Foo as Bar:

One could argue it’s not as “expressive” and more verbose – bu it’s definitely much more readable and would lead to less broken code. It’d be even better if they used the word “exception” or try/catch as all the rest of the world does 🙂

Some people in PHP community think all “shortcuts” are best to be avoided. I think some of them could be useful, provided clarity is not sacrificed and there’s not “too much magic”. I know it’s subjective but my personal criteria is that if it’s not immediately clear what’s going on for a person with reasonable knowledge of the matter – it’s probably too much magic.

On PHP features

When people ask why PHP doesn’t have this or that cool feature which allows to do some tricky mind-bending function and requires a dozen pages of manual to describe it, I find this quote from Brian W. Kernighan is very appropriate:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Corollary of that is that some clever tricks are better left not done and some cool things may not look that cool when you have to deal with the consequences.

That being said, I think there are many cool things yet to be done in PHP. So, I’ve posted a poll on Programmers.StackExchange site about what people want to see in PHP. I know people regularly post on PHP lists about that, etc. but I think SE crowd would be somewhat different from what is found on PHP internal lists, so it would be interesting to see what people’s wishlists for PHP are.

If you happen to want to add your 2c there or just vote on stuff – feel welcome. Absolutely no promises it would have any weight, influence anything (except maybe my own opinion about what people want in PHP), etc. of course.


Adding new extensions to Zend Studio

I am using Zend Studio for my everyday PHP work, and I like it. I know many others do too, or use PDT. It has one very cool – though not widely known – feature that allows you you to add unknown extensions to code completion. I.e., if you have some extension, create stub file with PHPDOC descriptions – i.e. something like this:

 * Do stuff
 * @param string $arg
 * @return array
 function dostuff($arg) {}

for each extension function, Studio will know to pick it up. You can put this file into Studio’s prototypes directory – easiest way to find it is just write something like chdir() anywhere, select the name and press F3, the directory of the file that you’ll get is the one you need.

However, the problem is how to create this file. E.g., I’m doing some work with MongoDB lately, and PHP has great Mongo extension – which Studio doesn’t know yet. So how do I create those stubs? Obviously, I am too lazy to manually write them. I went to look for a tool that would allow me to make one – and found none. At least not in 15 minutes I spent looking, so I decided to write my own.

What came out is the Reflector. It uses PHP reflection and PHP’s manual XML sources in order to generate stub file (see example mongo.php on git to check what comes out). Right now it’s not very smart and handles only classes/methods, not functions (probably will fix that soon), but maybe it will be useful to somebody.

Or maybe somebody points me to a tool that does that even better in comments 🙂

Update: Roy Ganor (who is leading the Zend Studio project) in comments pointed me to the source of the Studio generator script. It will generate stubs for all extensions you have, as I can see. Try it out. Thanks, Roy!


On Monday was my first day on a new job.
After 10+ year with Zend, I have decided that I need to change direction somewhat and do something a bit different. I was not easy to leave Zend, after so long time and departing from such great company that Zend is – it was a hard decision. But I felt that’s what I need to do, and so it goes. I have accepted an architect position at SugarCRM and that’s where I work now.
I plan to stay with PHP of course and continue to contribute to PHP core and ZF, time permitting 🙂

P.S. Also, Simple Cloud API, on which I was working at Zend lately, has Technological Preview Release. Check it out!