OOP is Mature, not Dead

I ran across an interesting series of blog posts by Karsten Wagner claiming that OOP is dead (part 2 and part 3). The premise behind these posts is that OOP has failed to deliver and that it is on the decline in favor of more functional or meta programming techniques. Maybe its true that the discussion of the merits of OOP is on the decline. At least if you read reddit.

However, OOP is not on the decline. Quite simply, it has become mature. The discussion may be on the decline because almost every language that anyone actually uses implements a core set of OOP features. OOP has won its arguments. Good luck taking a language mainstream without it.

Oh, yeah, there are some OOP features that are still controversial or unusual. There is the single versus multiple inheritance debate, or perhaps Ruby’s open classes. But, I think these things have a way of cross-pollinating across the popular languages when they make sense.

A good example of this cross-pollination is happening now with properties, accessor methods and the uniform access principle. Language support for declared accessor method is slowly creeping across all of the major languages. Not that Objective C is all that popular, but Objective C 2.0 adds support for ’em. Even stodgy old Java is considering language level property support.

Sadly, PHP does not yet have language support for declared properties with accessor methods. What are __get and __set? They’re property missing handlers, not accessor methods. You can simulate accessor methods with them, but that is a poor solution for most applications. There is no way to support differing visibility, for example protected setters and public getters. Property not found handlers are prohibitively verbose to write, have a poor performance profile, have no capability for reflection, cause interoperability problems, and have inheritance edge case gotchas (not present in the java beans model, for example). My hope is to see good language support for properties in PHP 6.

Closures may not be object oriented, but they seem to be undergoing that same language cross-pollination. Thats seems to be a pretty good sign that they are useful. It doesn’t have to be closures OR objects, it can be closures AND objects. We can use each when they make sense.

Closures are another wish list item for PHP 6. PHP is almost wired for them with its callback psuedo type. Everywhere you can use a callback in PHP, you could use a closure. I’d like to see the callback Pinocchio become a real boy like integer or boolean. The cool thing is that with PHP’s weak typing the string and array forms of the callback pseudo-type can automatically be converted to a native closure type when needed.

As I said, the core OOP features that most programmers use are in all the mainstream languages. The interesting part is how they handle the OOP edge cases. This is the space where the framework developers live. As I wrote in culture of objects, PHP has some problems here. In some ways I think Ruby’s support for edge cases is exactly what allow a framework such as rails to be built in it, although, I’m not familiar enough with Ruby to say for certain.

I think addressing some of these issues in PHP 6 will make it a Ruby killer for web applications. It isn’t necessary to be perfect here, just to be good enough and allow the larger community, distribution, and stability to take over. Unfortunately, there is a long lead time here. If PHP 6 were to add support for declared accessor methods, closures, and late static binding — my top three framework enablers — it would still be at least 2-3 years before PHP 6 was sufficiently deployed and the frameworks could adapt to the new features.

In the meantime, while the PHP culture may have problems, the Ruby culture may not be without its own problems. The influx of lisp and smalltalk programmers, two languages that did not go “mainstream” may prevent Ruby from going mainstream. Take a look at The impending ruby fracture. Isn’t this one of the things that happened to SmallTalk and Lisp? I’m still not convinced that Ruby hasn’t inherited many of the same maintenance problems from its Perl heritage. Just like english, huh? Only time will reveal Ruby’s maintenance characteristics. I give it about 2 to 3 years for today’s Rails systems to hit full legacy mode. How long do you think it will take for top notch unicode support in Ruby?

Obviously PHP 6 is all about teh unicode. Including an opcode cache is going to be an important performance and adoption driver. However, I’d like to see more progress on framework enablers. I really want to see these in the next major PHP deployment cycle and not in the PHP 7 deployment cycle. Are there framework enablers other than closures, declared property accessors and late static binding that I have overlooked?

I have high hopes for PHP 6 as a mature and mainstream language.

Speak Your Mind