Wednesday, July 28, 2010

Missing the point (OOP in scripting languages)

Yesterday I came across a question: Do Web-Scripting Languages Really Need OOP?
Here's my answer: only if you want to do more than an Hello World script (which is paradoxically how old school programmers measure the utility of a language.)
I'll express some of my thoughts without compromises, which will be up to you.

The author is equilibrated, as he saw the design simplifications that object-oriented programming introduces. However:
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.
This is not about 5 lines vs. 10 lines. If your projects are that long, go ahead. But hasn't the fact that every PHP framework is object-oriented told you something? The web is evolving from displaying documents to executing applications in the browser. The complexity will only increase in the future. When do you encounter 5-line script anymore?

What worries me are some of the comments:
However, in the PHP community there are very strong tendencies to cargo cult programming. Private methods and attributes make sense in Java, from where the idea was copied, but it adds little structural integrity in scripting languages (that's why Python eschewed them). But still, many PHP coders consider it "right OOP" to mark as many attributes as private as possible; neverminding that it only shadows underdesigned interfaces.
Private properties are available for encapsulation, not for structural integrity. I mark items as private so that I can change them in the future while only looking at the source code of their own class, and never worrying about external dependencies.
The likewise silly namespace\syntax also gets quite overused already. Deeply nested namespaces make sense in Java, but add little of the pleaded name conflict protection in PHP. It's just another syntax construct that gets used purposeless because it's hip. 
Namespaces are good because they remove duplication: you refer to the full class name (which can be quite long, such as Zend_Controller_Action_Helper or Zend_View_Helper_Url) only one time, at the top of your source file.

I'll give you one single reason to switch from procedural to object-oriented programming: seams.
In plain old structured programming, functions refer to other hardcoded functions, in a rigid graph. In OOP, object are (should be) wired at runtime, during their creation phase. It's this mechanism that makes practices like unit testing and polymorphism possible.


Kevin said...

Another good reason to use OOP in PHP is for autoloading. In other words, you can load only the part of application that is needed for that individual request, rather than having a butt-load of includes just-in-case-you-need-it.

Markus said...

The thing is, people who started using php "in the old days" are used to see php as a quick-and-dirty scripting language like bash. They just dont know frameworks like Zend or Doctrine that makes php to a real programming language nor they implemented a big application in php. So, no surprise they dont understand why OOP or Namespace exist.

Giorgio said...

Unfortunately dynamic pages built by submerging tags in HTML are not so versatile anymore for modern web applications, so we have to help PHP evolve or it will disappear. :)

Anonymous said...

Markus: "frameworks like Zend"... ~10% of ZF is OOP! ...and don't try to use ZF (<2.0) with namespaces :)

Tim said...

I don't worry about posts like that too much. I find that experience tends to teach why OOP is so useful. It's only a matter of time before that AHA! moment occurs.

mario said...

Not all PHP frameworks are object-structured. (Btw, "object-oriented" programming is for languages that are *based* on objects.) As example, Drupal is a procedural 'framework'. For polymorphism it uses function hooks, which are a dumbed down observer pattern, really. It's quite a large codebase. Given, they jump through a lot of hoops to get there, but it's questionable that it would be any more lucid if it was object-structured. This is strictly a notational decision, not a functionality or complexity limit. It might come as shock to some, but you can utilize OOP concepts in procedural languages and code too. Representation != functionality.

Giorgio said...

Since all modern programming languages are Turing-complete, functionality is equivalent from PHP to assembler. A simpler representation is what higher-level languages provide...

Wil Moore III said...

"and don't try to use ZF (<2.0) with namespaces :)"


I am using ZF < 2.0 with PHP 5.3.2 and using namespaces. I'm not sure what you are doing exactly but I'm guessing it's wrong.

Anonymous said...

Wil Moore III: hint: view helpers