PHP’s Simplicity Can Confuse Folks Looking For Complexity
Posted by Stuart Herbert @ 1:34 PM, Sat 05 Aug 06
Filed under: PHP
7 Comments
Chris, you’re completely missing the point about objects and PHP.
Classes and inheritence are not new to PHP 5; PHP has had these for many many years now. PHP 5 brings with it new features, such as interfaces, class constants, and access controls (although it’s still got a ways to go to catch up with both Python and Ruby). It also changes the semantics of objects; in PHP 4, objects are passed by copy, but in PHP 5, objects are passed by handle.
You can - and plenty of folks do - write object-oriented code in PHP 4 just fine.
PHP’s runtime behaviour - that each page starts afresh - is one of PHP’s killer features. You’ve obviously got no idea about just what a difference it makes. Every time your script runs, you’re guaranteed to start with a clean slate. The only state you have to worry about is the state you’ve stored for yourself. This simplicity makes it almost trivial to create deterministic code, without which you cannot produce high-quality code.
Managing state between pages is very straight forward in PHP. If the state matters only for the user’s current visit, put it in the session. If you need state to persist between visits, or it is information that other visitors need, put it in a persistent datastore (such as a database). Use a local cache (files on disk, memcached) to reduce the amount of time you have to get state from the persistent datastore. That’s the PHP way.
Folks who follow design patterns religiously are missing the point. They’re not hard and fast rules (that way lies Java, and its hideous and pointless complexity); they’re guidelines, meant to make you think about the natural structures that arise in your code. They’re not meant to be a cult. Anyone tells you different, they haven’t read enough Suzuki. When all you have is a hammer (or a set of design patterns), everything starts to look like a nail.
And that’s the beauty of PHP over many of the other tools that you have. If you want to write a system that’s entirely object-oriented, you can. But you don’t have to. You can create and use objects where they make sense, and you can continue to use global functions where they make sense. PHP’s neutral philosophy gives you the freedom to just get on with it, and do what’s right for your needs, your skills, and your tastes.
7 Comments
August 5th, 2006 at 5:28 pm
Hmm.. I eh.. think YOU have missed his point. He’s not looking for complexity, he’s wondering what justifies adding these complex concepts the ’simple’ a request a a time setting of PHP. I guess to him most of these new features are already part of that “hideous and pointless complexity” you attribute to Java.
I think that is a valid concern. Personally, as I work on pretty big PHP applications, I like this stuff a lot. However I am also worried about the overhead created by all this “indirectness”. When Java code passess stuff on and on through five objects, one can assume that the compiler cuts out most of the fat before the program is deployed. When Java kicks 20 objects into existence to handle a task, it will at least recycle them: those same 20 objects will be there to take the task on again when needed. Both are not so in PHP: the application will be recompiled and started up again and again for each request..
August 6th, 2006 at 2:07 am
I think you are missing the bigger picture that is manageable code and the long lasting debate over OOP. The point of ‘Database Abstraction’ is so that you don’t have to replace all of the mysql_* or mysqli_ calls in your script. The SQL is a valid point, but is also missing the point others have clarified before.
Debating OOP is pointless, it has been debated long before PHP and will be debated long after PHP. If you want to read intelligent flames, look at the old mailing lists that were around or ask an zealot on both sides. Interesting stuff as I have said countless times before and you’ll learn stuff.
I do agree that PHP handling of Objects could be better, but it is damn fast for what it does do. I have seen applications written purely object oriented and run just fine. I’ve seen function based applications offering the same pluggable code that are usually found in OOP.
You can do code any number of ways but to restrict yourself to one pragmatic approach is inane. Classes believe it or not make a lot of stuff easier with the use of design patterns.
If you need to reuse classes, serialize them, store them in either a database or file, and then unserialize them afterwards.
August 6th, 2006 at 8:18 am
I am also concerned about the increasing complexity in php. But IMHO this does not arise from the OOP options of PHP itself but from the unreflected use of java oriented design patterns. People port java approaches and class structures 1:1. This does not make sense.
For our (completely OOP) applications, porting from PHP4 to PHP5 saved at least 30% of lines of code and this is the biggest thing in PHP5 to me: Exceptions and Class Constants. Thanks for these, PHP group!
August 6th, 2006 at 1:33 pm
Wim - Objects do not add complexity - people do. Used right, objects make a big difference in simplifying code. But, as I said in my post, the nice thing about PHP is that you don’t have to use objects. You can use what is appropriate for the situation.
You can stop PHP recompiling your apps just by using Zend Optimizer, APC, or any other byte code cache.
Jacob - database abstraction at the (for example) ADODB layer isn’t the best way. Each database server has its differences, and to get the most performance out of each, you need to do more than simply rewrite the SQL syntax that you are using.
Debating OO certainly is not pointless. As an engineer, you should always be looking at the tools to hand - including OO - and asking yourself whether its the right tool for the particular job at hand, and whether or not there’s another way to use the tool. I worked on enough large projects over the last 14 years to have seen first hand what happens when some idiot tries to make everything OO without thinking first.
It’s a shame you weren’t at the debate I ran on the php|cruise conference, where we got into PHP and objects. It would have been interesting to get to talk to you in person about this.
Chris’ comments aren’t a flame. They’re ignorant and naive, typical of someone who’s near the beginning of his career. I’m sure I’m not the only person a little embarrased to see a post like his appear on Planet Gentoo.
Best regards,
Stu
August 6th, 2006 at 2:28 pm
Actually Stuart, what I meant was what you stated, so there is no argument there.
However, I took Wim’s comment as a procedural vs Object Oriented. That debate is pointless, since the project manager or team should choose one or the other or a mix of the two that is the best for them and stick with it. Also, what you mention too.
I’ve read enough of the debate to know that the real point is not about functions and objects, but what the person really thinks a person should use to make their code easy to manage.
I’ve also seen enough of OOP vs Procedural to know about the flames and that was what I implied, not Wim’s post.
August 6th, 2006 at 4:43 pm
Well, what can I say. When I saw your post I started with reading Chris’, via the link, and then yours. When doing so, I couldn’t figure out what got you so wound up - if I may say so. It seems to me that he, you, me, and pretty much all commenting out here so far are quite in agreement: don’t mindlessly add complexity, for example by 1:1 copying from Java, but think about the best tool for each job.
I didn’t mean to bash objects; I just picked them as the example at hand. Sorry ’bout picking such a sensitive one. Same concern goes for 20 near superfluous includes, or any other form of complexity needlessly getting out of hand.
Opcode cashing is great, but sadly not much in use by webhosts in general so far (the ones that complain when an app takes “too many resources”
). I’m therefore quite pleased that APC is going to be in the PHP core distribution. (Note: Zend Optimizer != Zend Cache, the optimizer only optimizes the opcode between compiling and executing.)
August 6th, 2006 at 7:07 pm
Much ado about nothing. I apologize then to you Wim, for my misinterpretation.
Yeah, I do very much love objects, but I’m not against procedural as I have used it in C++ and it works great for quick tasks. Which is why I’m not exactly a OO zealot and advocate whatever works best.
Add Your Comments To This Article Using The Form Below
Your comments may not appear until they have been approved by a moderator.