PHP5: Could PHP Soon Be Owned by Sun?

Ian Felton writes "PHP 5's official release occurred on July 13th, with a complete overhaul of object-oriented programming features and improved MySQL functions. These are sure to be great additions to the package for PHP developers. However, many of the changes to PHP are hinting at something that PHP developers might not necessarily like down the road." Read on for the rest of Felton's thoughts on the downside to corporate involvment in PHP's future.

At first glance, the obvious changes to PHP are a result of the success of the Java platform and the weaknesses of PHP revealed in comparison. With the release of PHP 5, it's apparent that the developers of PHP and the Zend Engine (essentially a single group) felt compelled to make PHP much more like Java with respect to object-oriented programming. Zend, the Israeli company backing the development of PHP, promises on their web site that "full integration with Java will be closer than ever before." Hmmm, full integration with Java, huh?

On November 4th, 2003, Zend announced a strategic partnership with Sun. This deal also included advisors from Borland, Macromedia, MySQL and others. The purported purpose of this deal was to make PHP part of Sun's web server and bring it to the corporate world of development that previously had been dominated by ASP and ColdFusion. Now with the release of PHP 5, it's far more apparent which path PHP is taking.

PHP's object model was re-written from the ground up and mimics the abstract properties of Java's object method. There are private and protected members and methods, abstract classes and interfaces, in practice, identical to Java's object model. The extent of the influence that Sun has on PHP today is clear. If you have experience with Java and PHP, reading the details of the object model reveals the absolute cloning of the Java object model within PHP 5. From throwing exceptions to static variables, PHP 5's object model mimics Java in concept all the way to the syntactical level.

This is great for enterprise developers using Sun products, but with the release of PHP 5, what does this mean for the half-million PHP developers worldwide who have depended on PHP for open-source development, or for the developers whose ideas and efforts have brought PHP up through the ranks from its inception in 1995? When PHP goodies were bundled with Sun's web server on November 4th, 2003, with a $775 price tag, PHP began down the path of corporate ownership. For years developers have eagerly contributed their ideas and efforts to be a part of the success of PHP. Now that all the hard work and volunteering has paid off and PHP is a worldwide success, it appears that PHP could soon be another corporate shill owned by Sun, MySQL, Borland and Macromedia, if not on paper, then by direct influence on the people at Zend. Of course it will remain open source so that those half-million developers can continue to contribute their time and genius to its success, but if those thousands of contributions lead to direct financial gain for companies whose coffers are already overflowing and are simultaneously using those contributions to manufacture software with price tags out of reach to anyone but corporations, is PHP still the language developers should be focusing on for use in the open-source community?

On the positive side, this edition of PHP does bring improved performance and a new suite of MySQL functions. Backward incompatibility is limited to a list of ten issues. Additionally, there are only minor configuration file changes that need to be made to the web server. Several directives have been introduced for configuring php.ini files, mainly dealing with hashes for encryption.

Some very useful functions have been added to PHP5. It's been nine years in the making, but PHP5 now includes two functions to uuencode and uudecode. Combining those functions with the new socket and stream functions, developers can create a lots of "kewl" applications. An application to automatically encode and decode files to and from news servers comes to mind as an example of how to incorporate these new functions. At that point of course, a developer could use any of PHP's existing functions to continue to manipulate the files, store the contents in databases, and so on.

An addition to error reporting aids developers in keeping their code up-to-date. The E_STRICT message tells developers when their code is using deprecated functions or is in danger of not being forward compatible. However, don't assume that E_STRICT will be output if using E_ALL, because it won't. E_STRICT must be explicitly declared to output its suggestions to PHP 5 code.

While the rewriting of PHP's object model to essentially that of the Java object model does raise flags about the direction of PHP, it is still a powerful addition to the PHP5 release. Java became successful for a reason: it's intelligently designed and facilitates code reuse. By borrowing the best features of Java's object model, PHP has leveraged itself with far more credibility as a programming language that can stand on its own two feet (even if Sun, Borland and Macromedia are holding it by its arms).

Some vital re-workings in the PHP object model lie in how objects are treated in low-level fashion. Instead of passing the actual object itself, PHP's object model passes by reference. Now when operating on objects, developers can pass around multiple handles to the actual object allowing for more powerful and efficient applications. Existing PHP objects do not need to be re-written to take advantage of this change in PHP 5.

In general, developers who have experience with Java will easily adapt to PHP 5's object model. On the downside, if PHP is a developer's primary language and he or she hasn't been introduced to the world of static variables, public and private methods and the host of aspects included with this new model, they may have a bit of a learning curve adopting the higher-level format of object-oriented programming in this release. Overall, though, this change will be a plus for creating large-scale, object-oriented applications with PHP.

Keeping pace with the developments in MySQL and PHP's tight relationship, PHP5 has added a new suite of MySQL functions relating to the new features added since MySQL 4.1. Denoted as Improved MySQL Extension, its purpose is to allow developers to take advantage of prepared statements and the other additions to MySQL 4.1 and above.

Something very interesting to note with the addition on the Improved MySQL Extension is the absence of bundled MySQL client libraries with PHP5. There are numerous reasons given for this, including the different licenses that PHP and MySQL are under (PHP is under a BSD/Apache type license and MySQL is under a GPL license). The PHP5 documentation also assures developers that "there will always be MySQL support in PHP of one kind or another," but doesn't go into details as to the future of MySQL support. This perhaps is further evidence that the long-lasting popularity of LAMP environments (Linux, Apache, MySQL, PHP) will soon be replaced by SLOP environments (Sun, Linux, Oracle, PHP). If Zend continues to shy away from MySQL and completely joins forces with Sun, MySQL may soon no longer be part of the picture, and cheap, fast development may no longer be possible for PHP developers in the same capacity as it is today.

Zend clearly has underplayed the extent of the shift that has taken place concerning the future of PHP. While this version of PHP does provide a much better object model and added features, is this the beginning of the end of PHP as the choice of web scripting language for the open-source community and developers not under the employ of corporations? Will the average developer still be using PHP five years from now, or will the usefulness of PHP be limited to companies who can afford to shell out thousands of dollars for all of the necessary software that may be required to make PHP a viable option for development (along with the purchase of products from Sun, Macromedia, Oracle, Borland and others)?

While today this is still speculation, the evidence and tone lends credence to the thought that with the success of PHP, built on the backs of developers worldwide, the near future of it may include an alienation of it from those who energized it at its genesis, propelling it to the corporate enterprise status that those in control of PHP are seeking today. No matter what actually happens, developers should be aware of the major developments with PHP beyond the surface level function additions and new object model. Companies and developers who are employing PHP 5 for large-scale applications today at a reasonably low price may be in for a surprise in the next few years, if operating PHP at full capacity involves the purchase of additional, expensive software.

PHP overview at K5

[Matt Perry]

There's a great overview [kuro5hin.org] of PHP5's new OO capabilities at Kuro5hin.

PHP also not an ASF project any longer

[gtrubetskoy]

Don't know if this is really relevant, but as is noted in the Section 5.G of Feb 2004 ASF Board meeting minutes [apache.org], the PHP project is terminated and rights for PHP will be tranfserred to the PHP group.

Re:PHP and MySQL?

[Electrum]

And as to MySQL, remember it's not as free as the rest. Like Qt and MySQL (Trolltech and MySQL AB) are both using dual-licensing to make their products "free" for some use, but not for others. MySQL's client libraries are GPL rather than LGPL, which makes using them for corporate projects less ... legal. It makes sense for a language like PHP to distance itself from such projects -- not eliminate support, just appear less entangled.

This is complete FUD. It doesn't matter that PHP uses the GPL'd MySQL client library. Code running under the PHP interpreter is not affected by the GPL.

Additionally, GPL incompatible applications can use the GPL'd MySQL client. They simply cannot statically link with it or distribute the client library. The user of the application would have to provide the library. Dynamically linking to a library does not cause any (copyrighted) code to be copied into the application. You have never needed a license to use a shared library.

Re:PHP needs to be re-implemented under GPL or BSD

[andig]

Before you write FUD you should really check your facts. The Zend Engine is under a BSD-like license meaning that it's here to stay that way.
And the PHP license you are quoting is old. Look at http://www.php.net/license/3_0.txt. I hope you trust urls to php.net

Andi Gutmans

Re:not quite.

[timotten]

Well, the grandparent's comment was pretty random, but it interested me, too, so I did a quick search of Google and a thread [sun.com] with a Java + protected + field problem. So I did my own test (with Blackdown JDK 1.4.1 for Debian).

First, recap. These points are usually mentioned in "Intro to Java" texts:

1) A class member marked as protected can be accessed from any subclass. A normal use cases might have a subclass modify some inherited field.

2) One instance of a class is allowed to access any member of another instance of the same class. This might be used when a node in a linked list examines its successor in the list.

Apparently, the interaction between these rules depends on whether the super- and sub-classes reside in the same package. Suppose we have the following:

class foo.Wonk
--> protected int fld
--> protected void mth()

class foo.WonkPrime extends foo.Wonk
--> void doThis(foo.WonkPrime sameInput, foo.Wonk superInput)

class bar.WonkPrime extends foo.Wonk
--> void doThat(bar.WonkPrime sameInput, foo.Wonk superInput)

Code in foo.WonkPrime.doThis can access this.fld, this.mth, sameInput.fld, sameInput.mth, superInput.fld, and/or superInput.mth.

Code in bar.WonkPrime.doThat can access this.fld, this.mth, sameInput.fld, sameInput.mth, and superInput.mth. But it can't access superInput.fld.