OOP is Mature, not Dead
January 7th, 2007I 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.
All Posts
January 7th, 2007 at 3:23 pm
I doubt, PHP6 will include any of those. Lead developers told several times, that they don’t want to make serious grammar changes. Closures were declined at some point, as far as I remember.
There is an opinion, that PHP’s core is not flexible enough, and rewriting it one more time (the first time was PHP3 → PHP4 transition) requires too much resources. The problems are just too deep
January 7th, 2007 at 9:51 pm
It’s possible to do something like the following to allow read-only access of protected members.
class SomeClass {
protected $val;
public __get($name) { return $this->$name; }
public __set($name, $value) { throw new Exception(); }
}
If a public-scope caller tries to access $someclass->val, PHP will translate it to __get(’val’). Of course, switch statements and better error handling would be needed.
For variable visibility when the variables aren’t known until runtime, I have come up with the following hack that makes it possible.
// Assert that caller is in the protected scope
assert($callers = debug_backtrace() && $this instanceof $callers[1]['class'])
// Assert that caller is in the private scope
assert($callers = debug_backtrace() && $callers[1]['class'] == __CLASS__)
Of course, these are just ways of forcing a square brick into a round hole. It would be much nicer (easier maintenance, better performance, …) if PHP supported this stuff natively.
January 8th, 2007 at 3:57 am
late static binding is also very high on my wishlist, but proposed patches don’t make it into the trunk. I don’t like the magic __get / __set methods for the exact reason you name: they aren’t accessor methods, only property missing handlers.
January 16th, 2007 at 3:08 am
__get / __set have problem with acces over array. http://bugs.php.net/bug.php?id=36484. In PHP overloading is not good implementation. PHP is very low-end programer language and his OOP model is bizzare.
BTW: I like PHP.
January 16th, 2007 at 3:09 am
BTW: BTW: sory for my bad english. English language ==4== in schooll.
February 5th, 2007 at 12:34 am
I’m afraid, PHP6 will not include those features. PHP developers are C (not C++) programmers, they don’t have sympathy for our OOP wishes
We must talk much louder!
ad accessor methods: an idea, how to simulate accessor methods with capability for reflection (and phpDoc). See http://www.dgx.cz/trine/item/property-setters-and-getters-final-solution
February 7th, 2007 at 4:08 pm
Thos blogs must have been interesting!
February 7th, 2007 at 4:11 pm
What does this OOP stand for?
February 12th, 2007 at 8:03 pm
I love the blog that you have. I was wondering if you would link my blog to yours and in return I would do the same for your blog. If you want to, my site name is American Legends and the URL is:
http://www.americanlegends.blogspot.com
If you want to do this just go to my blog and in one of the comments just write your blog name and the URL and I will add it to my site.
Thanks,
David
May 9th, 2007 at 11:51 am
your top three are perfrctly mine, but i would add a fourth:
4. traits or mixins
yes, i’m late but i just found the blog to the name
January 22nd, 2008 at 12:35 am
Just so everyone is up to speed, late static binding will be in php5.3 and 6. About bloody time! I’m looking forward to implementing some very sexy architectures.
March 15th, 2008 at 9:02 pm
OOP is the industry AND academic standard. There are still many people hanging on to procedural programming, like hanging on the edge of a cliff. Programming procedurally in the 21st century is like riding a horse into battle against an tank brigade.
If you don’t understand OOP, you’re gonna be in trouble in a few years.
PS. There are instances where OOP is still standard such as microchip programming. But there are good reasons for that!
April 6th, 2008 at 11:33 pm
OOP is a tool, not a religion and of course it will not fit all projects.
HOWEVER …
OOP is an academic and industry standard. I dare say for the most part, projects are developed with the OOP philosophy, or a philosophy that is similar to, or not mutually exclusive from OOP.
There are cases where PURELY procedural programming can still work, but to be honest, I cannot think of many.
The fact is that since the “software crisis”, it just hasn’t been acceptable to write spaghetti code and procedural programming is mostly conducive to that.
Again I say … if there is a situation where a certain methodology is really warranted, then its OK.