Upcoming PHP 5.3 features and beyond

By Manuel Lemos

manuellemos.net

<email contact>

Contents

* Who is Lukas Kahwe Smith?
* Wiki at php.net
* PHP 5.3 features overview
* Performance versus memory usage
* Lambda functions, closures and PHAR
* Future PHP 5.x versions
* What are traits?
* PHP 5.x versus PHP 6
* PHP 6 release
* PHP 6 adoption
* Helping in PHP development
* Conclusion


* Who is Lukas Kahwe Smith?

files.phpclasses.org/graphics/lukas ...

LKS = Lukas Kahwe Smith
PC = PHPClasses (Manuel Lemos)

PC: Lukas, can you please tell a bit about yourself, where do you come from, where do you work, and what has been you participation in the PHP group?

LKS: My name is Lukas Kahwe Smith. I have an east German mother, an Iranian father and an American stepfather. So there is a bit of almost everything in me. To complete things my step sister is Jewish. Well far east is still missing.

I started a company with a few friends from high school using PHP and MySQL. I think in 2002 or 2003 we went to Frankfurt for the international PHP conference. This was really my step into becoming part of the open source community and not "just" a user.

We actually met you (Manuel Lemos) there and based on your recommendation, the PEAR community suggested that I work on a merge of PEAR::DB and Metabase. After that I became quite involved in PEAR.

Slowly I shifted my interest towards PHP internals as due to work standards I was using less and less PEAR stuff. I started maintaining a wiki of all the open to do tasks, which has now spawned the creation of the official wiki site.

wiki.php.net/

In the summer of 2008 I was then asked to join Johannes as release manager to help out with the organizational aspects.

I sometimes pride myself in being the only non-C coder that has php-src karma. :)

By the way, the PHP Group is actually a small number of people that are sort of the legal entity behind PHP. As such I am not a member of that group. I usually refer to the people working on PHP as the php.net crowd.


* Wiki at php.net

PC: Nice. Can you talk a bit more about that wiki in php.net? What is its purpose? Who should participate in it? How can an interested member of the PHP community get the necessary permissions to participate?

LKS: The purpose if the wiki is to improve the collaboration. So for example we use it for the to do lists for the various active branches. We also use it as a "scratchpad" to note things that need to be added to the manual.

wiki.php.net/doc/scratchpad/upgrade ...

The various teams inside PHP.net are also using it to note processes. Like there are pages that explain how to build PHP on windows.

wiki.php.net/internals/windows/step ...

The biggest thing that came out of the wiki is that people started writing RFCs when they were pitching bigger (and even some smaller) changes.

wiki.php.net/rfc

This makes it much easier for people (core developer and end users alike) to follow what is going on without getting those fairly useless "check the archives" replies. Now they can be pointed to the RFCs to see why something was done the way it was done, or why something was rejected.

One of the big concerns with the wiki is that people would use it as a replacement for adding things into the actual end manual and its something we have to constantly look out for.

The other concern was that content would quickly become unmanageable. As a result we only have people with a CVS account to any PHP.net project write access.

Everybody else can read everything and, of course, request an account. We will then ask the purpose and give access rights. So far all changes people wanted to see happen were either done by granting them access or someone else taking care of this. We are quite liberal here.


* PHP 5.3 features overview

PC: PHP 5.3 is about to be released. Can you give a quick overview of the most important features introduced by this release?

LKS: The biggest and most controversial one is obviously name spaces. We are aware that several people object to our choice of the separator but unfortunately we were unable to find a better alternative.

Other than that a lot of under the hood changes will give people a considerable speed boost, especially if they are not using a byte code cache.

Furthermore we added lambda functions and closures, as well as added some constructs to make working with static methods more powerful.

We also added several extensions of which I especially see PHAR being of huge importance, as it might define the way we package applications in the future.


* Performance versus memory usage

PC: Regarding performance, historically it seems that many performance improvements were made at the expense of greater run time memory usage. Do you agree? Can we expect noticeable increase in memory usage of PHP scripts as consequence of optimizations done on PHP 5.3?

LKS: I am not really an expert, since I do not know the PHP internals. There are some optimizations in PHP that should reduce memory overhead. Constants are now marked as constant internally. I guess in the past they were handled like normal variables, with simply no way in user-land to modify them. I am not sure how much of a difference this will make.

For people running into issue with memory consumption there is now a tool to get a better handle on this. PHP has trouble automatically freeing the memory when you do cyclic references:

$a = new Foo();
$b = new Bar();
$a->bar = $b;
$b->foo = $a;

In large complex scripts constructs like this happen more often that one would expect. Thanks to GSOC 2007 we now have a tool to collect memory when $a and $b are unset.

This does add some memory overhead to track all of the necessary information. However the benefit is that you can either automatically have PHP trigger or manually trigger a process that looks for cyclic references that can be freed up. With a bit of CPU work, this can mark a world of difference for large or long running scripts.


* Lambda functions, closures and PHAR

PC: Can you give a little more detail about what are lambda functions, closures and PHAR and what that is good for, to clarify those that never heard of those features before?

LKS: Lambda functions and closures really are great when working with one of the many internal functions that use callback functions.

Now, instead of polluting your name space with functions you will only call once and thereby risking a fatal error when you have overlapping function names, you can now create an anonymous one shot function on the fly.

PHAR is the result of a "proof of concept" PEAR package called "PHP_Archive".

pear.php.net/package/PHP_Archive

It allows you to run an archive of several files just like you would be able to run a classic PHP application. So essentially you can take your application, tar it up and have your customers drop this in without having to extract the archive contents.

PHP can read this archive very efficiently. Even byte code caches can handle PHARs. The performance is really good, in some cases due to reduced disk I/O it can even be faster, but I have not checked the latest benchmarks in a while. I think its clear that this reduces a lot of the code maintenance nightmares.


* Future PHP 5.x versions

PC: What features do you expect or wish to be available future PHP 5.x versions?

LKS: Well, I am really unhappy that we did not manage to include traits into PHP 5.3. But something we had to give up, as we were struggling with getting 5.3 out the door because we already had so many features that needed attention. That being said, I do not expect a PHP 5.4.


* What are traits?

PC: Can you elaborate on what are traits and what they are good for in a typical PHP project?

LKS: We do not have multiple inheritance in PHP. The closest we offer right now is being able to implement multiple interfaces. We felt that there is too much of a WTF? factor when two classes have conflicting method definitions.

Traits try to solve the issue differently. Essentially traits are like copy and paste, with a simple syntax to handle any arising conflicts explicitly, which hopefully gets rid of the WTF? factor.

So with a trait you can define and implement your methods in one place and then have those implementations be essentially "copied over" by PHP.

Sounds complex? Its actually quite a lot easier than I think I am making it sound here. Stefan Marr has written an updated RFC that explains everything (including the research behind this).

wiki.php.net/rfc/horizontalreuse

A possible use case is the classic "Active Record" problem. Forcing all your model classes to inherit from a common base class is really an ugly clutch, but currently there isn't really a very efficient alternative.

With traits you would not have to do this, as you would simply use a trait for the storage related methods and import them into any model class.


* PHP 5.x versus PHP 6

PC: Andrei Zmievski is basically the architect of the main PHP 6 feature, which is the native Unicode support for representing text strings.

He was in Brazil last October in a great PHP event named CONAPHP - Congresso Nacional de PHP:

conaphp.com.br/

Andrei gave a talk named "PHP for Grownups - How 5.3, 6, and intl will change your life" on which he mentioned that PHP 6 is basically PHP 5.3 plus Unicode support.



Do you expect that any other improvements to PHP that will be pushed to PHP 6 rather than future PHP 5.x versions?

LKS: Right. This will remain true for the most part. Andrei is now back on making PHP 6.0 happen, since his new employer is able to give him the required time.

As such we have not made a final decision, but from the vibes I have been getting from most people I talked to on this topic, we might see a PHP 5.4 eventually if we find that the step from 5.3 to 6.0 will be a hindrance to the adoption of 6.0. Or in other words PHP 5.4 might come out after 6.0 is out to backport some features (for example traits). But first we need to figure out PHP 6.0.


* PHP 6 release

PC: Andrei mentioned that PHP 6 is expected to be released some time later in 2009. Do you have a more specific expectation for a release date?

LKS: Based on the experience with PHP 5.3, I would say it will be hard, but not impossible, to even make it in 2010.


* PHP 6 adoption

PC: I think PHP 5 suffered a long delay in adoption mostly due to backwards incompatible changes that would require existing code to be rewritten.

Often companies did not want to spend more money on rewriting code that just works in PHP 4. Do you agree? Do you think PHP 6 may also suffer of that problem? If so, do you expect it to be worse problem under PHP 6?

LKS: Not really. Of course backwards compatibility issues played a factor. PHP 4 was simply quite good. PHP 5 brought with its new features that needed a lot of education for the vast numbers of self taught PHP developers.

Most PHP developers do not have a computer science background, so they did not really understand the new potential of all the new OO features. So it took some time for people to start implementing frameworks and tools to make those new OO features usable for the great masses of developers.

As such PHP 6 will be in a different situation. It will for the most part "only" add Unicode support. While I am sure that many novice programmers struggle with encodings, it will be quickly evident for all users that do have to deal with non ASCII encodings, that its easier to use PHP 6.

The main challenge will be making sure that the performance will not suffer too much because of the obvious additional work that needs to be done behind the scenes to have an engine that is actually encoding aware.


* Helping in PHP development

PC: What can interested developers do to help to make PHP developments come out faster?

LKS: Write tests, write documentation, test our preview releases. For the first part I would suggest to join the test fest efforts, which is a global event that tries to encourage end users to participate in the efforts to write tests.

qa.php.net/testfest.php

As for writing documentation we have also worked hard to reduce the barrier to entry. For one the process is now better documented and the tool chain is now entirely comprised of PHP .

wiki.php.net/doc/scratchpad/howto

wiki.php.net/doc/phd

For running tests, we just ask people to follow the news on the PHP php.net Web site.

php.net/


PC: How can anybody contact you to get more information about PHP developments and how they can help?

LKS: What I suggest to subscribe to one of the many mailing lists and simply lurk a bit. Sooner rather than later an opportunity to jump in an help will come.

Also remember that talk is cheap, so I recommend to just try and do something. People who do things will find that there are plenty of people willing to steer them in the right direction. People that just talk have a tendency to just use up time in endless discussion.

Another approach is to hook up with one of the many physical or virtual user communities. Going to a conference to network, or better yet an unconference, which at a much lower price tend to encourage active participation and networking even more.

I can honestly say that joining PHP.net has made me a better programmer and has been my single most effective career building step. My employer also benefits from the huge network of people I know.


* Conclusion

PC: Lukas, thank you for this interview.

LKS: I appreciate your efforts to make PHP code more accessible and to enable people to share their code.


PC: As a side comment, I would like to mention that the PHPClasses blog system, which is custom tailored like everything else on the PHPClasses site, was recently enhanced to allow submission of articles written by any user of the site.

If you or anybody else would like to submit articles of general interest of the PHP community, feel free to do so by going to this page. The site has a reasonably large audience, so posting interesting PHP articles in the blog will give you great instant exposure to any issue that you feel is of the interest of the PHP developers.

phpclasses.org/blog_post.html


LKS: OK, good to know. I might make use of this at times.

PC: Feel free to do it. Thank you.