The scale that Cal is talking about is actually better known as modularity:


| Few large modules ---- Sanity? ---- Many Small Modules |


If you haven’t listened to Alan Kay talk about the benefits of many small modules, you should do so now. Alan Kay coined the term Object Oriented. Love OO or hate OO, if you have an opinion on it, you should know what he was thinking. Hint, it wasn’t C++.

On the other end of the scale, One Giant Function is generally known as Big ball of Mud(PDF) Here is Brian Foote’s presentation on the paper (read the paper first).

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.

Writing doesn’t come easy to me. Writing this blog for the past two years has helped me improve. However, I have to admit that I was quite worried just before the column was due. I just re-read it for the first time since turning it in and I am happy with the result. This is due in no small part to some great advise and encouragement from Marcus.

This month’s column takes on the topic of organizing code. I wanted to convey some of the fundamental principles underlying the object oriented paradigm, but in a way that goes beyond objects. In the mid 90’s, I had what I consider a major professional epiphany when I finally understood object oriented programming. This month’s column is my best attempt to concisely explain the heart of that epiphany.

I’m proud of this month’s column. I hope you’ll check it out.

Chris Shiflett has some thoughts about the security corner column in the same issue.

Joshua Eichorn (among others) notices that active record can’t work as shown in the Zend Framework webcast. The syntax presented during the web cast is not possible in PHP because of inherited static methods are treated. Mike Naberezny notes the problem and suggests that it will end up getting fixed in PHP:

We’ve been working on the solution to the problem with statics on the C front, so eventually it will be solved there.

In the sitepoint thread Trouble in Zend Framework Land?, 33degrees smells vaporware:

I find it amusing that they did the webcast using that syntax, while there is currently no way of implementing it in PHP5. Makes you wonder how much code they’d actually written at that point.

Elizabeth Marie Smith does too and adds:

I find it rather annoying that they haven’t fixed the problem BEFORE now – after all, the bugs (marked bogus or wont fix because obviously the zend guys weren’t using php5 at that point if they didn’t see the problem until zend framework came along) the bugs/requests have been around for a LONG TIME

I look at this incident as an incredibly good omen. My optimism about Zend’s PHP framework is not for the framework itself, but for what it means for OO support in PHP. In my book, the more developers that have commit access to both ZPF and to PHP, the better PHP 6 will be for me. I look at ZPF as an important step in building a culture of objects in the PHP community.

What?

In my previous post, I talked about how the leaders of the agile development culture seemed to be migrating from Java to Ruby with nary a glance at PHP. One of the reasons is that PHP lacks a culture of objects.

Support for object oriented constructs in PHP is relatively new, rough, and uneven. PHP competetors Ruby, Python, Java, and .NET all have OO class libraries, yet PHP does not. The classes and interfaces that PHP does have are not necessarily what I would hold up as paragons of modern OO design.

I can see why this would be the case. PHP is written in C. Being an expert in C programming does not necessarily make one an expert in object oriented programming (nor does it preclude it). My impression from reading the php-dev mailing list is that of a C culture rather than a object culture. (witness the goto vs exceptions debate.)

I’ll save any critique of PHP’s built in classes for OO for future blog posts. Instead, lets look at PHP’s documentation. I regard PHP’s online documentation as excellent. Its one of the factors that drew me to PHP in the first place. I especially like the comments system. Yet, go the the front page and search for one of the built in classes. Try “exception.” Helpful? Did you know to switch the dropdown from the default functions option first? I’d like to link to the documentation for the Exception class. Where should I link? Classes are not first class citizens in the PHP manual as functions are.

Try searching for the ‘getTraceAsString’ method of the Exception class. I’d like to leave a comment about it, where should I go?

My purpose is not to run down PHP’s support for objects. Merely to suggest that there is more work yet to be done for first class support.

Ok, so PHP doesn’t exactly have a culture of objects. Who cares about objects?

To answer that, I want to explore the complex relationship between PHP and Zend. A good way to highlight the distinction is to look at the PHP usage numbers and the adoption rates for PHP 5. While web hosts account for the vast majority of the PHP usage numbers as reported, they have been slow to convert to PHP 5. On the other hand, Zend reports that 50% of their customers have adopted PHP 5, suggesting that Zend’s customers are a bit different than the general PHP using population.

I think the PHP 5 adoption rates show that Zend’s customers care about objects. I suspect that some of the object support in PHP 5 is a result of feedback from Zend’s customers.

Zend is not a charity. I would imagine the ZPF project consumes a great number of resources and they are doing it for a reason. I think Zend’s customers also care about frameworks. It sure looks to me like the ZPF project was triggered by Rails.

So somewhere in the ZPF project, they should be trying to do the same thing in rails and in ZPF and comparing the code. (if they don’t there are a bunch of bloggers, me included, who will do it for them.) I’m sure their customers will do it too. Perhaps the Active Record syntax shown in the webcast was inspired from such a comparison? I think that in order to look good in these comparisons, some aspects of PHP’s object support are going to have to be improved. Static inheritance won’t be the last thing to get fixed.

Its is the zend framework effort thats going to put the finish on what PHP 5 started. I honestly believe that PHP 6 is going to end up a runaway success. (Is it still true that only the even numbered star trek moves are good?)

So if PHP doesn’t exactly have the best reputation as an object oriented language, what can we do about it. Or specifically, what can Zend do about it?

Well, when Microsoft was being criticized for the lack of patterns in their PetStore example, what did the do? One, they fixed it. Two, they hired Martin Fowler’s company to write about .net patterns. Ever notice how many .Net patterns there are in Martin Fowler’s Patterns of Enterprise Application Architecture Book?

I’d like to see Zend hire a reputable object guru to help PHP turn around its object reputation. This should be someone who is known outside the PHP community, someone who has been going to OOPSLA for longer than PHP has existed. Someone who has a book on object oriented programming, articles, a blog, and who is an expert at teaching object oriented programming (10 years to be an expert). Writing and teaching help hone ones thoughts and this job requires a communicator.

To start, Zend can put this person to work both advising on ZPF and telling the world about ZPF. However, I would hope a longer term goal would be to apply some deep experience in coordinating and advising on the classes and interfaces that are going into the language itself.

I would hate to see the sales objection “php’s functions are inconsistent” morph into “php’s classes are inconsistent.” Not only that, today’s class and interface designs are going to be around a long time. Public refactoring is not a good in a language class library or in a widely used framework. Witness the slow adoption of PHP 5 and the problems with reference changes in 4.4, 5.0.5. Deep experience can help get a better design at the outset.

I for one welcome our new object oriented overlords.

Ruby on Rails today looks poised to eat Java’s mindshare on the web tier. If not Rails, then something else.

It does seem like Java’s mindshare is on the decline, along with sun’s fortunes. There is some evidence that rails is drawing mindshare from PHP as well. (Mind share is the grown-up way of saying “what the cool kids are doing.”)

So why isn’t PHP that something else?

i think its the unit testing, “You aren’t gonna need it,” “Do the simplest thing that could possibly work” folk that are dismantling Java’s mindshare. As they gain it, Java loses it. Some of that is showing up in the java community itself in concepts like POJOs and dependency injection. Some of it shows up in an exodus from Java to dynamic languages.

So why are the agile leaders like Martin Fowler and Dave Thomas working with Ruby instead of PHP? David Heinemeier Hansson directly credits these guys with influencing his decision to stop programming rails in PHP and move to ruby. I suspect that its the dynamic, smalltalk, like features of Ruby that appeal the the agile methods leaders.

Rails could have been a PHP framework, but wasn’t. Although, I’m not sure that it would get the attention it is if it were a PHP framework. The rails, ruby combination may be greater than the sum of the parts.

I can’t speak for anyone else, but I have some ideas about why PHP might not appeal to the agile method and java is too complicated folk:

• Too many globals – globals make unit testing more difficult and prevent integrating work from different developers, let alone different organizations.
• No culture of objects – PHP has made great strides in this area, but I don’t get the impression that many of the folk that work on and with PHP really buy into object oriented programming the way that the agile methods folk do.
• Crowded namespaces – How many functions is PHP up to? Constants?
• incomplete component model – This is another integration thing. PHP has too many islands and not enough continents. (I’m talking beans here, but definitely not EJB.)
• No mature frameworks – Ruby has been around a long time, but didn’t really start gulping mindshare until Rails came along. See The Value of MVC.
• No closures – Its a dynamic thing.
• Expert level gotchas – hopping on the learning curve is easy. Reaching the top, not so much.

I’ll elaborate on each of these points in a series of upcoming posts.

I’ll close by saying that life is not a zero sum game. The success of Ruby and Rails does not diminish the success of PHP. The cool kids were doing Java and now some of them are doing Ruby. Oh, well. Its disappointing that more of them aren’t doing PHP, but PHP has many things going for it. That, however, is a different series of posts.