Digging in our code looking for PHP 4 code I can break?

Fri, Jul 6, 2007 03:10 PM
So, some PHP projects have banded together to put the final death nell into PHP4.  They call it GO PHP5. The Phorum team received an invitation to join them. We didn't officially join the list.  With Phorum, we have always written our code to do the job that needs to be done.  I have never really looked at the docs for a language and thought "oh, where can I use that in my code".  That seems to be the direction this is going.  From time to time we have had to bump up the minimum versions of PHP and MySQL that are required for Phorum.  Those have been done because we had a problem that could not be dealt with in some older version.

Now, what the Phorum team is doing with Phorum 5.2 is writing it with PHP 5.2 and MySQL 5.0.  We have done zero testing on PHP 4.  We don't really plan on it.  We are not however going to purposely break PHP4 which is the feeling I get from the GO PHP5 camp.  Is there a good chance that we will use some function that is not available in PHP4?  Yeah, probably.  Will I care when I use it?  No.  But, am I going to go find a function and use it just so my application is PHP5 only?  No.  If we finish it and it works fine in PHP4, I am not going to lie to my users and tell them it won't.

Maybe its OOP that is driving this.  Phorum made a decision when we started 5.0 that we would not use OOP in the core.  We did it for speed reasons.  Speed was most important to us.  PHP OOP creates (it seems better now than then) overhead that we don't want or need.

Maybe I took it all wrong.  I don't know. I don't mean to offend.  But, I also don't want to be on the fictional list of projects that are not "PHP5 ready" because we are not publicly throwing PHP4 into the ether.
12 comments
Gravatar for Chas. Root

Chas. Root Says:

I guess I should open by stating that while I understand the developers desire to drop
continued/extended support for php4, I think it is not unreasonable to continue
supporting it as Apache has done with it's 1.3x version. Which I believe still holds
the lion share of installs. But unfortunately, judging by the comments on the list(s),
the developers seem to look on version 4 as the "red headed step child". As such
can't wait to bury 4 forever. This is really a shame. Given that they owe most of their
success and popularity to v.4.
 I've just spent the past 2 mos. evaluating every CMS/blog/forum and related
application available. Anything dated 2004 to date - some 375 in all. All of which
were PHP based. In doing so I have discovered a great deal regarding PHP.
Interesting enough, php4 is much like LEGO(tm). It isn't OO but you simply
"plug-in" any desired functionality. This approach _really_ lends itself to flexibility.
It also makes it easy to keep your application lean, as you only add or "plug-in"
what you actually need. It also makes development a snap. Classes are small
and easy for developers to create, and within reach of almost any development skill
level. No wonder v.4 is so popular. Just look at all the php classes available as proof.
In evaluating all those applications. I also couldn't help but notice that those that
had a minimum v.5 requirement were much larger than those with a v.4 min.
requirement. Drupal included - are you hearing this Larry Garfield? ;)
I evaluated Drupal. It is feature phat. But left a larger foot print than I thought
necessary to deliver those features. I could easily see how I could achieve the
same results in v.4 (php) with currently (and freely) available classes and have a
much smaller foot print. I can only surmise that the development was done in
anticipation of moving to v.5 (again, php). Which simply proves my observation -
php v.5 applications will invariably be larger than their v.4 counterparts. So truly,
where is the gain? Speed? Doubtful. Larger almost always results in being somewhat
slower. Features? Then which ones? UTF is well supported in all of my v.4 base
installs. But I suppose that there _are_ some UTF _enhancements_ in v.5. But still
not enough to _compel_ an immediate upgrade. So what is it really? OO? I think
there could be _many_ arguments on both sides where OO is concerned. My roots
are in assembly. So when all the hype about OO started in the mid 90's, I was in no
hurry to jump on the band wagon. This does _not_ mean I am an opponent. I just
do not feel inclined to use it because it's the "newest" "bleeding-edge" thing that I
_must_ use. Hell, I used Macros in assembler. Which is pretty much pseudo OO.
Point being, OO should be used when it is _truly_ more efficient. I think the biggest
grievance I recall hearing when the php developers announced that v.5 would be
OO based. Was that Sun Microsystems was responsible, as they had made a large
contribution to the development of PHP, and ultimately directed it's course. See
Larry Garfield's comment above "The extended OO support is what got the most
press". _This_ is _why_ it got the most press. Am I saying OO is bad? No. I am not.
It's just that is is _not_ the be-all-to-end-all that it is touted to be. _That_ is my
point. There _are_ times when it is better in fact. But _requiring_ one to use it, was
probably _not_ the best decision to make, where php was/is concerned. So. In my
humble, or not so humble opinion, php v.4 should be allowed to live life for as long
as it is still deemed useful. It should be allowed to continue to live life as Apache's
v.1.3 web server has. It should _not_ be deemed the "red headed step child". But rather,
an alternative to v.5 (or 6).
Note to Larry Garfield:
I am not singling out Drupal as a bad piece of software. My _only_ reason for using
it, was that it was a _convenient_ example. Because you already made reference to
it in this blog. I have absolutely _no_ ill feelings about it - or you. :) My statements
were not, and should not be considered a personal attack on you or your software.
You seem a very kind soul. Thank you in advance for your indulgence. I look
forward to any rebuttal you (or anyone else) would care to make. :)

Gravatar for t5727

t5727 Says:

What really separats PHP5 from PHP4 are the extended OO capabilities (well, if you need them). If you just want to use some newer PHP5 functions, then running Phorum on PHP4 versions is not endangered. Search for "upgradephp" or "php_compat".

Gravatar for Larry Garfield

Larry Garfield Says:

The Drupal announcement specifies "Drupal 7". Drupal 6 just went into feature freeze and should be out well-before next February, but Drupal 7 has almost zero chance of being out before February, so it would be the "next feature-release". The link to GoPHP5's site is sufficient to mention February.

Gravatar for Just to clarify my feelings for PHP4 « Rambl

Just to clarify my feelings for PHP4 « Rambl Says:

[...] to clarify my feelings for PHP4 I think my earlier post has been misunderstood.  I am in no way advocating keeping support for PHP4 by the PHP team [...]

Gravatar for Larry Garfield

Larry Garfield Says:

Hi Brian. I think there was definitely a miscommunication if that is how you understand the GoPHP5 effort.

I'm one of the site's co-founders, and the one who contacted you previously about GoPHP5. What you describe for Phorum 5.2 is exactly what we are encouraging.

No, we are not requiring that you go out of your way to break older versions of PHP. However, involved projects are committing to not care if they break older versions of PHP. Need prepared statements? Use mysqli or PDO. Those don't exist in PHP 4? Who cares? If you're going to do anything with JSON, you could roll your own JSON parser or use the one built into PHP 5.2. The fact that it's only an optional module in 5.1 and not available before that is irrelevant. On the other hand if you have no reason to use JSON, then don't bother. Oh, there's a bug in this function that was fixed in 5.1.4? Great, then we don't need to worry about it because we're assuming people have a version later than that.

The Drupal project's announcement is, I think, a good example of the way we're encouraging projects to go about PHP 5:

http://drupal.org/gophp5

It also has nothing to do with OOP. I personally don't believe that all-OOP makes any sense in PHP apps because of the "shared nothing" architecture. I'm a professional Drupal developer, and as of Drupal 6, due out this fall, we still don't have a single class anywhere in core. That may or may not change once we start using PHP 5, but I don't think anyone is planning to gut the system and make everything an object.

I hope that clears up our position. The invitation to sign up with GoPHP5 still stands, and is open indefinitely. :-) Please feel free to contact me if you have any other questions or concerns. (Contact form on GoPHP5.org, or my own site.) Cheers!

Gravatar for doughboy

doughboy Says:

Hmm, I see no mention on Drupal's page about the Feb. cutoff. But, that is a required statement to join the project list according to the entry form on gophp5.org. Or am I misreading that?

Gravatar for Larry Garfield

Larry Garfield Says:

Sorry, t5727, that's just not true. The extended OO support is what got the most press, but there are other language features that are just as if not more important (although some of them use OO).

- XML parsing in PHP 4 is like pulling teeth. In PHP 5, it's dirt simple.
- PDO gives you prepared statements for your SQL with a single, unified API across all databases.
- foreach() by reference makes changing a data set much easier and faster.
- The filter extension, if used properly, makes it more work to make your program insecure than it does to make it secure.
- Native JSON parsing makes writing Ajax-based applications faster and easier.

None of that relates to the advantages of having more robust OO tools available to you.

Gravatar for Tony Guntharp

Tony Guntharp Says:

I think this is being partly driven by the fact that supporting older versions of PHP is creating quite a bit of overhead and that web hosting providers need to update to a stable, updated version.

Afterall PHP5 was released on July 13th, 2004 and that on the proposed date of Feb. 5th 2008 it will be 3.5 years old, stable and mature.

I'm not going to mention the project I'm involved in but an end user was complaining the other day that something was broken and when asked for more details the end user in question said he was running Apache 1.2 with PHP 3.

Gravatar for Patrick Smallwood

Patrick Smallwood Says:

An example might help. Adding in a robust, tested, reliable, and secure input filtering solution is a *large* amount of work for any project. Yet in PHP-5.2, the input_filter is included by default. People can't widely use it if they need to support PHP4.

A project choosing to use the input_filter is making a tradeoff - less coding work to create a solid input filter, in exchange for losing all php4 users. Until this initiative, that was a non-starter. But with major projects getting behind GoPHP5, its much more reasonable.

Its less about finding solutions that won't work on older versions, and more about being able to reliably use new functionality that is truly a time saver. Then add in *full* unicode support? Absolutely huge difference in development times.

Sure, you can code alternatives in userland in PHP4. I'd rather spend the time making my product better, and thats what GoPHP5 is about. :)

Gravatar for Noel Darlow

Noel Darlow Says:

Supporting an older version of php creates extra work for the php developers and for other open source programmers. To me it's a question of courtesy, of trying to make life easier for people who contribute to the pool of free software from which we all benefit. A reasonable period of time has elapsed since v5 was introduced and it's time to move on.

Noel

Gravatar for doughboy

doughboy Says:

Hmm. I guess based on some of these comments that Phorum has been on this plan for a while. If we wanted to use input_filter we would have. I never imagined that the problem was that projects were making their code suffer by not using the right tools for the job they were trying to accomplish. But then again Phorun has never been a project that catered to the lagging masses because we were afraid of losing market share. You could of course argue that our install base has suffered because of that.

Gravatar for mmalone

mmalone Says:

I don't get the impression that they're trying to "break PHP4" at all. They're simply saying that they will no longer support it, which is not at all the same thing. It's been over 7 years since the first stable release of PHP4, the fact that _anyone_ is still supporting it is insane.

I sympathize with the providers who are afraid of breaking existing sites by upgrading to PHP5, but as a developer I'm tired of having to worry about supporting old PHP4 installations. At this point, I completely ignore PHP4 compatibility when I write software. But even with the tiny amount of visibility most of my mini-projects get, I'll inevitably get a half dozen comments/emails from people wondering why they can't get my software running in PHP4. It's damned annoying, and it's a waste of time.

Comments are disabled for this post.