[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ossig] Building a culture of objects in PHP
Jeff Moore at
Jeff is a well known PHP developer.
This is a follow up post to Why isn't PHP the natural successor to Java?
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
" 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
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
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
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
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
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. :)
To unsubscribe: send mail to firstname.lastname@example.org
with "unsubscribe ossig" in the body of the message