Thoughts on PHP 5.5

In my Summer of Learn article, I mentioned how I hesitated to explore PHP 5.3's features and plan to use 5.4's much more freely. In following with that general trend, I have been keeping up with proposed changes to PHP 5.5. In a recent post, nikic did an excellent job summarizing the major proposed changes that are being discussed in the mailing lists. While these features are still in the distant future, it is nice to think about them and try to understand the changes before 5.5 comes out so I can best utilize them when it is time.

I won't go over all of the changes, since new functions like boolval and array_column are pretty straightforward and don't need a lot of commentary on my part.

What is under consideration?

Simple Password Hashing API

I think this is a fantastic concept that should have been implemented a long time ago. As I wrote in Summer of Learn, I only adopted bcrypt within the past few months and was previously rolling my own sha1 salted hashes. Part of the reason for this may have been the relative complexity of implementing bcrypt compared to sha1. A concise, easy to use password hashing api could do wonders with the upcoming generation of PHP developers and stop that bad habit from ever forming in the first place.

Constant Dereferencing

I'm at a loss on this one. I actually have no idea what the point of this is. The only example they showed was to fetch a random value from a hardcoded string. That seems like a very arbitrary example that I cannot translate into a real world use case. But, I will admit my previous experiences are limited in scope and the usefulness of constant dereferencing may be lost on me. I'm not chomping at the bit for this feature, though.

Parameter Skipping

Dear God, why? Why not allow for named parameters? Why are we putting in place a tool that will encourage excessive parameter lists? One of my favorite quotes on programming is "If you have a procedure with ten parameters, you probably missed some." I think a trend towards smaller functions with more manageable parameter lists is only a good thing. So to add a feature that encourages lengthy, optional parameters is absolutely horrifying.

Getters and Setters

I really like this concept, but would be even more thrilled with some kind of Python style descriptors mixed in. Being able to define a specific getter and setter for member properties is great, but is just asking for excessive boilerplate code for standard operations. My magic column technique makes heavy use of getters and setters, and this proposed feature could streamline that significantly and increase readability.


This is the feature that I am most interested in. Just like with getters and setters, this could dramatically streamline my magic column technique. As it stands right now, the magic column is able to dynamically pull large quantities of related data, but it must all be pulled upfront. A generator would make it much easier to only grab a small range of data at once. I hope this feature makes it to 5.5.

What is missing?

With this list of changes, there are bound to be features that I would like to see but are not even being discussed. The most significant two are named parameters and descriptors. Named parameters will help with the much discussed needle/haystack problem and get rid of the ugly parameter skipping proposal entirely. Descriptors would reduce a lot of boilerplate code, especially if all functions become first class objects and everything is mutable in this regard. A few other small features I'd like to see are tuples and improved interaction between errors and exceptions. Overall, this is a good set of changes. The only one that I am dreading is the parameter skipping. I pray that they reconsider this awful notion and don't encourage such a bad practice.