There’s a alot of talk about how great PHP5 is going to be (and it will be great) but I wonder if it’s making many PHP coders nervous?
This is some thoughts about “Why PHP5?” [WARNING - this turns into a rant towards the end - couldn’t help it]
Luis Argerich, maintainer of PHP XML Classes as well as (ex) Wrox author (did some great work on Wrox PHP XML) recently posted an article on phpBuilder - Introduction to PHP5 which surveys some of PHP5’s new features with code examples.
It’s interesting to note some of the comments the article drew; seems to be some nervous reaction to PHP finally getting serious about OOP. From occasional remarks on other PHP community sites, I wonder how many PHP coders share similar views - a fear that PHP 5 will suddenly make the language inaccessible?
If that applies to you, it’s worth noting Zeev Suraski's comment on the article;
“all of the structured code features remain intact. PHP‘s built-in functions are and will remain procedural.”
It’s worth remembering something the core PHP development team frequently repeat: PHP is, at heart, a down to earth language which is accessible to all. This is what’s made PHP a massive success.
"May as well be Java"
The new object model does bear many resemblances to Java but that doesn’t make PHP5 Java.
Java is a highly respected language which has it’s place, but for someone trying to negotiate the maze of standards, libraries and techniques who, in the end, just want’s to build a content management system, it’s overkill.
What’s more, even for experienced Java programmers, it’s a tough language to “whip up a prototype in”, being strongly typed and verbose as well as “compiled”. This is acknowledged by Jython, an implementation of Python in Java.
Python, BTW, isn't miles apart from PHPsolid Python projects which PHP could benefit from.
The point is PHP5 remains a loosely typed language, allowing both procedural code as well as solid OO code to a level which is comparable to Java.
That means we can still “whip up an app” in a matter of minutes but when it comes to delivering it to a customer, it can be “packaged” in an acceptable commercial form.
PHP5 had to Happen
...just to silence the Perl coders ;) ( Actually it’s a shame that in some places PHP and Perl seem to be head to head - not always though )
PHP is being widely used but has yet to make significant impact in the enterprise ( with some exceptions ). When you start explaining the details of PHP4 to someone who knows what they’re doing, the subject of workarounds pops up and it starts to get embarassing. It takes an really enlightened management to risk the business on PHP today.
Put in a sentence; if we want to get paid what we deserve as PHP coders, we need PHP5.
If that’s not enough incentive, note that even JavaScript has exception handling... coming with PHP5.
What’s more, given the rework of the overload extension to become a core feature of PHP5, PHP is in line to become a platform which can unify Java, .NET, COM and Python ( may be even (*deprecated link* and Perl ) on the web, as well as being the language for stored procedures in MySQL.
Also, given solid OOP, it’s likely that PHP will attract more experienced software developers, perhaps from the Java camp, which in turn is likely to bring further quality to the wealth of Open Source projects written in PHP.
Too Abstract!
Hopefully this site provides some examples of why OOP in PHP is worth getting to know. As a subject OOP has way too many advocates pushing vague theories and benefits (and usually using Cars to make their case) IMO. OOP in the end really isn’t that exciting - it’s just a way to organise your code to make it easy to work with in future.
Sterling Hughes made an interesting point in a recent interview.
“What I object to is people who use OO to develop large, overly-abstracted reusable frameworks, encapsulating all their logic within the object itself. These frameworks, especially in the webspace, tend to be more complex than the problem they originally set out to solve. "
While I can see that being misquoted as a reason to ignore OOP but note that he’s talking specifically about frameworks.
Building abstraction and delegation into your code is much like layers of middle management - the more you have, the less anyone knows about what’s really happening (or when it will get done) and in the end someone has got to do some real work.
That said, some frameworks have got it right. From my standpoint the two frameworks in PHP which have reached the level of being serious enterprise contenders (no offence to any other frameworks but these two have a commericial element which is a critical - you can buy support for example which keeps the managers happy). The two are eZ publish and Krysalis.
eZ publish I know well and have been getting into version 3 recently. This site took about 1-2 weeks to finish with eZ publish 2.2.x (mainly as a result of the template system, which is pretty inefficient). With eZ publish 3 my guess is I could have cut that down to 1-2 days.
Krysalis I haven’t spent much time on but from what I’ve seen it has an excellent design (which is critical if you want to build apps on top of it) based on Cocoon. Aside from extensive the use of XSLT (which would help development teams work with designers using standard design tools), Krysalis would make a powerful tool for deploying and consuming web services. It was examined in Wrox PHP Web Services and the chapter can be found online here. Also interesting is Komplete Lite which is a branch of Krysalis geared purely to content management. Could be an ideal blogging tool.
Getting back to the point, frameworks are a double edged sword.
They (should) make is possible to develop applications quickly, given understanding of the framework and should provide a structure which encourages good design (e.g. seperation of application logic from presentation logic). This takes much of the “risk” out of application development - with a framework you can narrow down the uncertainties and likely always deliver “something” to your client.
The flip side is if you write you application for a framework then later decide to ditch the framework, it’s likely your code goes with it (i.e. you have to re-write from scratch or reproduce the framework).
Procedural Code Forever!
PHP 5 gives us a chance to start building solid libraries of classes. Code that makes it easy to display your content in PDF form, for example. One problem I ran into when developing the PDF version of this site was with HTMLSax, when I accidentally used a variable in my subclass with the same name as one already used by HTMLSax - I wasted about 30 minutes on a bug hunt before I realised what I’d done, time which could have been saved with PHP5 assuming the variable has been declared as private in the parent ( I hope ).
Now I could have written my own code to do what R&OS PDF does, using purely procedural code (having understood the PDF format) then cried “sucks to OOP - procedural forever!”.
Of course the year would now be 2038 by the time I’d finished and I’d be starting to worry about Unix timestamps instead.
The point of building libaries is to encapsulate the solutions to problems in an API which will meet most (if not all) requirements and thereby avoid the need to solve that problem again.
Shunning object orientation outright is like refusing to use a car on grounds that you can build your own wheel.
I’m not saying procedural code is bad - it’s often a powerful way to prototype applications quickly and on the web, when constructing a presentation logic layer, it’s often more flexible and easier to use procedural code than object oriented. With eZ publish 2.2.x, for example, the “views” are all handled by procedural code which tie together underlying classes handling application logic and data access.
Both are simply tools in the bag which you use when you need to - preferring one over the other is simply illogical captain.
Fear and Loathing
For me the real thing to be afraid of is not PHP going the way of Java but simply being eclipsed as a primitive technology for building web solutions.
The “competition” in the form of Microsoft with .NET have put together a solid class library and backed it with tools that make it easy to knock up applications using those classes. Meanwhile Sun haven’t been idle with J2EE either.
If PHP continues to be used as a procedural only language with developers perpertually reinventing the wheel, turning out apps which become ridiculous to maintain the moment you add some complexity, PHP will be dead within 5 years - if it takes a day with .NET but a month with PHP what would you choose?
Of course that’s an extreme statement but if the PHP community put itself to turning it’s experience of solving web related problems into re-usable classes there’d be no question about what makes the right choice for the Internet. We might hear Microsoft complaining about PHP‘s monopoly...
PHP 5 gives us the opportunity to evolve. A chance for resources like PEAR and PHP Classes to offer code which makes building complete, complex and maintainable applications a matter of days rather than weeks or months.
Right now PHP is the most popular technology on the Internet for building dynamic web applications, an amazing achievement in itself. When you consider the future, it looks like the server side is narrowing to a choice between three technologies - .NET, J2EE and PHP. Of the three, spot the loosely typed language...
Done right PHP has a natural edge on the web in terms of rapid (and cost effective) development. Done wrong and your clients will be asking if your code comes with bolognaise...
OOP - just a tool
Anyway - enough ranting. If PHP 5 makes you nervous, sieze the moment and start learning the class syntax in PHP 4 so that when PHP 5 comes around it’s just a question of learning some new syntax. There’s a list of useful places to get started (*deprecated link*.
OOP is just another tool to get the job done in the end - it means learning some new syntax and and learning to think a little more “outside the box” but that’s about it.
At some point I’ll do my bit and get round to a comprehensive introduction to OOP in PHP (no cars - promise).