Do Web-Scripting Languages Really Need OOP?

Nov 25, 2010 Author: LinuxAdmin

The object-oriented revolution has not been without controversy. Although many programmers embraced OOP quickly, others preferred the procedural approach they were used to and wondered aloud if the extra machinery needed to support OOP wasn’t more trouble than it was worth. Still, there’s no doubt that the revolution has largely succeeded. Most of the popular programming languages in use today are either fully object oriented or have object-oriented extensions. Also, at least some of the promises about improved productivity and increased code reuse seem to have been realized, as design methodologies like the Unified Modeling Language (UML) and patterns gain greater influence, and as people get more used to subclassing as a standard way to reuse and extend vendor-supplied libraries.

We feel that the benefits of OOP for “major” (that is, compiled) programming languages like Java and C++ are clear. On the other hand, we feel that the benefits of OOP for scripting languages (like Perl and PHP) are less obvious and are most debatable in the case of web-scripting (PHP).

How is web scripting different from other kinds of programming tasks? The most obvious difference is simply that web scripts typically execute quickly and then go away. In other programming situations, you may have RAM-resident objects that live for hours or days and undergo complex evolutions of state that affect their behavior. A typical web script, on the other hand, might execute for half a second, as it serves up a particular page, and then dies happy.

You may knit these scripts together to provide a more extended user experience (using databases, sessions, cookies), but often such efforts are all about making the experience outlive any PHP objects that may be created. More generally, scripting languages like PHP and Perl typically have a less thoroughgoing implementation of OOP than languages like Java, C++, and Smalltalk, and the limitations of implementation make these OOP extensions less attractive. (For more detail, see the sidebar “How OO is PHP?” later in this chapter.)

This is not to say that there aren’t still benefits of OOP in PHP. In addition to the conceptual benefits that may result from structuring code in an object-centered way, there are two good reasons to use PHP objects: 1) It’s a good way to distribute third-party code for reuse; 2) Many programmers who are used to OO syntax from other languages won’t feel comfortable unless they can use the same idioms in PHP.

But our main point is that use of PHP constructs for OOP is a very “tradeoffy” and pragmatic decision, which we have often seen made more on the basis of religion or fashion. If you are comfy with OO, this kind of syntax is there for you, and if you work in a group that has decided to write in that style, you may want to let the majority rule.

If you decide not to go OO, however, be strong — we urge you not to be swayed by the moral-superiority arguments you may hear from people who disdain your five-line procedural script in favor of their ten-line OO script that does exactly the same task.


views 6700
  1. Add New Comment