22 commentsAs PHP developers download and start testing the biggest change to the language in 7 years, many are wondering not about Santa’s bag full of new toys for them to use in building tomorrow’s applications but about the changes in the language that will affect yesterday’s applications.
The good news is that if you’ve been keeping your applications current with the language and best practices, there are very few things that could affect you. The bad news is that the farther away from the current version of the language you get, the harder it is going to be to port your code. For developers coding against the 5.2 branch, there are a few edge case situations of which, you need to be aware.
What follows is not a list of all the new features in PHP 5.3, there are many good references around the web for that information. The following is a distillation of the PHP 5.3 migration guide. We only cover those items most likely to affect legacy 5.x code.
Array Processing Functions
Previous to 5.3, many of the array processing functions could take either an object or an array and work. With 5.3, many of them change to array only. If you want to access an objects properties with one of the following functions, you will need to cast the object to an array first.
- natsort()
- natcasesort()
- usort()
- uasort()
- uksort()
- array_flip()
- array_unique()
Change to Magic Methods
Previous to 5.3 the magic methods could be declared as something other than public.
- __get()
- __set()
- __isset()
- __unset()
- __call()
Starting with PHP 5.3, these methods have to be declared as public and cannot be declared as static.
Deprecated
PHP has a list of functions that have been marked for removal. Most of these aren’t in common use but if you have legacy code, you may want to scan for them. The functions marked as deprecated are:
- call_user_method()
- call_user_method_array()
- define_syslog_variables()
- ereg()
- ereg_replace()
- eregi()
- eregi_replace()
- set_magic_quotes_runtime()/magic_quotes_runtime()
- session_register()
- session_unregister()
- session_is_registered()
- set_socket_blocking()
- split()
- spliti()
- sql_regcase()
Additionally, several directives in the PHP.INI file have been deprecated. If activated, they will now emit an E_DEPRECATED warning.
- define_syslog_variables
- register_globals
- register_long_arrays
- safe_mode
- magic_quotes_gpc
- magic_quotes_runtime
- magic_quotes_sybase
Since anything emitting an E_DEPRECATED warning will potently be removed from the next version of the language, these are hints to developers about to what to start looking at for PHP 6.
Undeprecated
In 5.0, the is_a() was deprecated in favor of instanceof, however, it was not removed from the language. In 5.3, that decision is reversed and is_a no longer throws an E_DEPRECATED warning.
Reserved
The following two keywords are now reserved:
Given the nature of these two keywords, it is doubtful that they exist often in legacy code. However, it is probably a good idea to scan legacy code looking for them. If they do exist, they will cause the parser to throw a parse error. They cannot be used as function names, class names, etc.
Conclusion
That is it. The complete PHP 5.3 migration guide can be found in the documentation on php.net. There aren’t many things in PHP 5.3 that will prevent well written PHP 5.x code from running. PHP 5.3 is much more about adding to the language than subtracting. If you are worried about your code not working in PHP 5.3 or would like to see how the new features of PHP 5.3 can help streamline your code and make your systems run faster, Ibuildings offers a range of code auditing and consulting services and are eager to assist you.
Thank you
It often goes without saying that we appreciate the hard work that everyone who contributes to PHP put in. I don't think it should go without saying though. I think everyone should personally thank the developers who put their time in to make PHP. So on behalf of all of us here at Ibuildings, thank you PHP core team. (Phergie, beer core devs)
22 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Nice migration article :)
Wow, has it been 7 years since the introduction of PHP 5? Seems like just the other day....well, forget PHP 5.3, let's bring on PHP6! :)
Great informative article - summarises the changelog perfectly :-) thanks!
IIRC, PHP 5 was released in the 2004.
Nice overview, thanks for that.
goto future;
echo 'PHP 5.2.x';
future:
echo 'PHP 5.3.x';
(Sorry, that was filtered out in my previous comment)
Count me among the Teeming Millions who believe that the initial implementation of namespaces in 5.3 is badly broken.
1) Use of the backslash as a separator is grossly counterintuitive; the implementor thereof should refrain from mind-altering substances while updating language specs;
2) Why can't 'using' do the job right? If I state that I'm using a namespaced entity, I should then be able to reference that entity as if it is in my current namespace; if I understand correctly, I've still got to include the innermost namespace, a backslash, and THEN the entity being referenced. Many, many hours of debugging will ensue from that implementation decision.
3) Would it really have been that hard to support namespace definition and using clauses sprinkled throughout the source file, as in many, many other languages? Doing so would have given far greater flexibility to client code at what has to be minimal implementation cost.
4) I could go on, but shooting fish in a barrel with a howitzer gets boring after the third shot or so...
I have been an enthusiastic user of and evangelist for PHP for ten years now. I'm working on a Web-development book that features PHP (5.2). PHP 5.3 has dimmed my enthusiasm considerably. I expect that I will soon polish up my mod_python and Rails skills, with a view towards presenting alternatives to clients. I am quite sure I am not the only experienced PHP dev taking this decision.
Continuing the Discussion