I’ve come around again to looking at PHP5 for a few projects. I started with some small self contained pieces that could be easily tested on their own. To be fair I wrote this code to only work with PHP5, trying to take full advantage of the new features. I quickly developed two complaints:
-
NO MULTIPLE INHERITANCE?
I like being able to re-use code, multiple inheritance should be a no brainer here. After digging around Google trying to figure why they would leave this out of PHP5 the most common excuse seems to be that it might be confusing for some people. After all, what if method foo() exists in multiple parents? Big whoop, establish a rule on how to deal with that and move on. Perl’s solution to this I believe is left to right, with ways to override that if needed. Continuing the argument against multiple inheritance it has been said in order to implement you can use interfaces. This is completely bogus! Interfaces have a use, multiple inheritance isn’t it. How can you have code re-use in an interface since it is specifically there not to implement code? -
EXCEPTIONS DON’T HANDLE ERRORS?
After getting over the feeling that PHP5 is trying to impress Java, I’ve been happy with having exceptions in PHP5. Unfortunately I was foolish enough to assume that normal errors in PHP would throw exceptions that I would be able to easily catch. Bzzzt, wrong! Turns out that exceptions are basically a ‘userland’ sort of thing, the system will still chuck errors the way PHP4 did. To get around this I wrote a simple error handling function that simple took an error and threw an exception using the error information. This adds another layer of code calling set_error_handler() and restore_error_handler() before and after a try and catch block that might cause a PHP error. Although I couldn’t find any documentation to confirm this, I suspect this was done in an effort to try and preserve backwards compatibility with PHP4. I would have rather seen additional knob that would use set_exception_handler() or something to make PHP4 code happy.
I generally try not to run around ranting against this and that, I just feel strongly that PHP5 missed out on some very useful and very important steps. I’m still a big fan of PHP, I consider it one of the best languages for web apps. Unfortunately that doesn’t keep me from being disappointed in what could have been for PHP5.
8 replies on “Two Complaints With PHP5”
Actually, I don’t think multiple inheritance is a must, sure it’s a nice feature, but sometimes it gives painful headaches, and it’s often misused and it got a bad reputation from those misuses. It probably took long sessions for Java designers to decide that Java doesn’t need multiple inheritance, so we’ll have to stick to the next best thing.
I was writing a kind of unit testing suite, but found out that PHP5 does not take PHP errors as exceptions. Just like you said. So I came accross your page by googling on the subject. This is very sad. I was just being amazed by the restore_exception_handler when this sh#t hit me. Thanks for the set_error_handler advice.
There is a performance hit associated with multiple inheritance. And you incur the hit whether or not you choose to use it. The choice not to implement multiple inheritance seems to be the more popular choice. Only C++ choose to implement it.
I never suggested that multiple inheritance would be a free feature from a performance stand point. I do contend though that abstract classes are not a substitute for multiple inheritance.
In addition to C++, multiple inheritance is supported by Perl, Python and Eiffel. Likely more, but those are the ones I can think of off hand.
with php5 this issue really should have been resolved. … as i really hoped it would.
[…] really should have included lack of namespaces in my complaints about PHP5. If that was bugging you too then you’ll be happy to hear that PHP6 will have […]
I agree with the two complaints. There is no significant thing of multiple inheritence in PHP5.
I think multiple inheritance is a near necessity for large scale applications. Sure, most people don’t need it, but for some applications it is incredibly useful and helpful. Interfaces achieve an entirely different result, I don’t know why people always say “use interfaces instead” that makes no sense to me.