Development

Been getting quite a bit of questions about PHP’s place in PZ. Here are some questions and some answers…

Why PHP?

Three words… Agility, Content, Educated. Yes, PHP is the A.C.E. up our sleeve.

Agility. If JEE applications are optimized for “enduring value” (A.k.a. they are written to run forever) then PHP scripts are optimized to “be running by this Friday” (A.k.a., they allow code to be written quickly and compactly, which is fine for many situational applications that spring up.)

Content. We call it “programming by cut-and-paste”. With PHP there are tons of assets available on the net. It is rare that you ever write something from scratch. Search, cut, paste and away you run… (This brings us back to Agile.)

Educated. It is really easy to self-Educate with PHP. It is easy for many people, even for people without formal computer science education, to write PHP scripts. For example, the complexities of Memory management and threading are not at the forefront of your mind when you are scripting in PHP. And back to my last point, much of the time you are modifying someone else’s code.

PHP is not the dynamic scripting language that Ruby or Groovy are.. This much is true. However, these languages have a long way to go before the most popular applications in the world get written on them (think Wordpress, PHPBB, etc.). As long as there are extendable PHP applications, new people will be learning PHP. Given that most of the tools popular with college students are written in PHP, there will continue to be a new breed of PHP programmers for Project Zero to accommodate.

Where is your PHP coming from?

Starting late last year, we’ve been working on a PHP interpreter from scratch in Java to serve as the PHP implementation for Project Zero. Since then, we’ve made some great headway. The wiki pages linked to from our PHP Language support page indicate how much of the language and existing functions we currently support.

Why not PHP.NET?

You might ask – why not use the php.net runtime? You can ask the same question of the JRuby and Jython developers. The answer is, the Java VM can actually reasonably host other programming languages, and in fact there can be some real advantages to having all your runtime code running on a common core.

Where are we at with PHP?

One effort that we identified early, relating to PHP in general, was enhancing the number of test cases that the php.net runtime uses to help maintain release-to-release compatibility. This is based on our experience with the huge number of tests that Java uses for the same purpose. Looking at the PHP tests, we realized that PHP could really use more test cases. And so we sponsored some colleagues to specifically look at adding to the base of test cases. You can see an example of this from the Zend Weekly Summaries Issue.

It should be obvious that we should be able to use these same tests to test our own PHP interpreter, and we’ve been doing this almost from the beginning. We’ve had the developers who are working on our implementation also contribute test cases back to php.net via the QA mailing list, as they’re developing their code.

What are we doing for Tooling?

We’ve been targeting the PHP Development Tools (PDT) extension from Eclipse, which provide a fantastic set of tools for PHP developers using Eclipse. The only real hole for us was the debug story, since the only debug protocol supported was the proprietary Zend debug protocol. Turns out, there’s an open source debug protocol called XDebug available for PHP, and we thought: 1) it would be nice to support this in the PDT itself; 2) we should use this as the debug protocol for our PHP interpreter. Doing both of these, and we’ll have debug capability for our runtime. And so we did. Recent versions of the PDT available from Eclipse are shipping with XDebug support provided by one of our developers. You can see some evidence of this by the noticing the ‘debug’ items in the PDT 1.0 Features Proposal.

What’s coming in PHP?

Obviously, we want everything better, stronger, faster. Where we can, we’re aiming to do things that benefit both the php.net runtime community, and our own interpreter. Most of our efforts in the near future are all about extending the number of functions that we support, since that’s our biggest hole. To put some practical focus on that, we are looking specifically at the phpBB application, to target being able to run it in our own runtime.

Our current story for building new ‘extensions’ for PHP involves an interface we call XAPI-J, which allows you to build extensions for our PHP interpreter in Java much like you would build extensions for the php.runtime in C.

We are also investing an alternative interface we call XAPI-C. Rob Nicholson mentioned this last week in his blog entry PHP Library Progress. The idea with XAPI-C is to take the existing php.net extensions, apply some macro magic, potentially some light code rewrite, and make those extension shared libraries available to Java through JNI. This is similar to the technique that Rubinius is going down for Ruby.

Groovy or PHP?

People sometimes ask me if there is a rule of thumb for using PHP and/or Groovy in Project Zero. My personal opinion would be – If you are a Java engineer, Groovy is the way to start. Java engineers are longing for the agility characteristics that Groovy provides. We want to encourage them that they can have their “cake and eat it too”. Or should I say, they can have their “Java and do Dynamic scripting too”. However, if you don’t have a strong Java background, and/or if you are looking to leverage pre-existing Content on the Web- PHP offers the means to create agile applications quickly.

Anything else?

Our PHP Interpreter is packaged as an independent Ivy package. We’ve adapted the Zero runtime to work with our interpreter, just like we did with Groovy. The advantage to this is that the interpreter might be used in other environments besides Project Zero. We have debated the idea of moving our PHP interpreter (again, like Groovy) into a project unto it’s own – where it can explore better compatibility with php.net as well as pursue supporting a full complement of PHP applications. Thoughts?

- Jerry