×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP5: Could PHP Soon Be Owned by Sun?

timothy posted more than 9 years ago | from the or-not dept.

PHP 76

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

76 comments

PHP pwnz Sun (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9903209)

And it also pwns ASP!

PHP also not an ASF project any longer (4, Informative)

gtrubetskoy (734033) | more than 9 years ago | (#9903340)


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.

Fork it (4, Insightful)

hoggoth (414195) | more than 9 years ago | (#9903345)

All of these comments are irrelevant. These predictions of PHP's future may come true or may not. But if you don't like the direction PHP takes, fork the project, take the source code, remove the parts you don't like, grow it in a direction you do like.

See that's why Open Source is different than proprietary software. It's not just another choice, it's fundamentally DIFFERENT. Nobody can take the software and force it down a direction you don't like because you and like-minded individuals can take it in the direction you like.

Re:Fork it (3, Insightful)

Enrico Pulatzo (536675) | more than 9 years ago | (#9906219)

It's funny that people claim this is a strength of Open Source, but when someone forks a spec, flames reign supreme. Can anyone explain why this is? I'd really like to know how forking and introducing proprietary featurs is okay for some projects, but on other projects it's not.

Seriously consider the differences between say, Microsoft forking HTML, and GNU forking ANSI C. I know that the Linux kernel can pretty much only be compiled by gcc since the kernel depends on gcc proprietary extensions, yet feel outraged that a company dare to do the same to a (wildly) popular markup language.

Microsft/HTML and GNU/ANSI-C (was Re:Fork it) (1)

Kalzus (86795) | more than 9 years ago | (#9906528)

Microsoft, long ago, felt it had a stake in reshaping the nature of browsers. Personally, I don't think the GNU C Compiler folks feel they have a stake in reshaping the nature of compilers.

Re:Microsft/HTML and GNU/ANSI-C (was Re:Fork it) (0)

Anonymous Coward | more than 9 years ago | (#9906703)

Actually the Free(sic) Software Foundation really wants to embrace and extend. It's one of their modus operandi. Go read up.

Re:Microsft/HTML and GNU/ANSI-C (was Re:Fork it) (1)

Junichiro Koizumi (803690) | more than 9 years ago | (#9997750)

Take a look at the "Extensions" sections in the gcc texinfo page. texinfo, of course, being the utterly broken and brain-damaged replacement for man that GNU hippies have forced on the rest of us.

Re:Fork it (2, Insightful)

Drywall (100602) | more than 9 years ago | (#9906663)

HTML is a client-side thing, and thus is very subject to a network effect: its only useful if lots of people are using it and can be counted on to use it. M$ "forking" HTML is problematic because it balkanizes the installed user base into different camps supporting different specs, thus reducing the utility of HTML as a whole (or something like that).

When a project like PHP is forked, it's true that it may divide up the developer base somewhat, spreading communal development resources more thinly than they otherwise might be. But it's not a project that's depending on end-user consistency in the same way as something like HTML.

That's my explanation anyway.

(Not that different browsers do a particularly good job of all displaying the same HTML the same way, regardless of the spec, but that's another conversation entirely...)

Re:Fork it (0)

Anonymous Coward | more than 9 years ago | (#9909724)

That's my explanation anyway.

And it's 100% correct.

The difference is absolutely that the standards Microsoft buggers up^W^W"extends" are client-side standards, i.e. the user needs to use Microsoft software to use them. Whereas the standards that GCC extends are irrelevant to the user, who either has the knowhow to install GCC or couldn't care less what compiler his kernel was built with.

The other difference is that MS products cost money: if you write an OSS program that depends on a Microsoft compiler, I can't use your source code unless I pay for the compiler. GNU products are free; if your product depends on GCC, and I don't have GCC, I can get it without paying a penny.

Oh, and GCC actually has a standards-compliant mode built in, so people using it can easily write standards-compliant code if they want to, and know that it will compile in any ANSI C compiler. Hands up everyone who can develop a reasonably complex website, testing only in IE, and reliably predict what it'll look like in Mozilla?

Re:Fork it (1)

adolf (21054) | more than 9 years ago | (#9928047)


It's funny that people claim this is a strength of Open Source, but when someone forks a spec, flames reign supreme. Can anyone explain why this is?


Probably for the same reason that people are up in arms about the transition from XFree86 to X.Org. Or, maybe it's the same reason people are really upset about forking Ghostscript. Or CDDB/FreeDB. Or OpenOffice/OpenOffice.org. Or Netscape/Mozilla/Firefox. Or rxvt/aterm, even.

(Oh yeah, that's right. People seem to like these forks.)

If PHP development heads in a direction that a majority of those who give a shit think is wrong, forks will happen, and be embraced.

If people end up not liking a fork, it's likely to die.

Re:Fork it (1)

SirTalon42 (751509) | more than 9 years ago | (#9973927)

Wow I never knew about an OpenOffice/OpenOffice.org fork... (I thought it was always OpenOffice.org)

And your exactly right, if people like the fork better than the original, the fork will take over really (or because 2 seperate products), and if they don't like the fork, well it won't get very far now will it?

Re:Fork it - Send 2 powerful messages (2, Insightful)

gd23ka (324741) | more than 9 years ago | (#9913913)

True. Forking PHP and building a successful community around the fork would send two powerful messages to corporations. Message 1: You can profit from OSS but you can't (successfully) dictate its politics. Message 2: Normal people are in control of OSS, not corporations. If you ask me, Message #2 will upset them the most.

Re:Fork it (1)

johnnliu (454880) | more than 9 years ago | (#9917254)

Yes, you _could_, but everybody will just end up in different camps and each zealously fighting each other over their own "superiority".

I'm always reminded of ATOM and RSS.

Yes, there's always choice, but it saddens me to see smart people with lots of energy, fighting each other instead of creating one wonderful product.

At the end, the consumer is always the ones suffering. If there was PHP-A, PHP-B, PHP-C and all of them are not compatible, how do you plan to jump from PHP-C-0.9 (discontined) to PHP-A-v2? What if I don't really care for the 'philosophical differences'?

I don't like this - so I split. This is Babel.

Educational. (4, Interesting)

EvilJohn (17821) | more than 9 years ago | (#9903379)

It seems Microsoft isn't the only one capable of spreading FUD. If PHP gets to far into someone's pocket, it will get forked into something more palatable to the community.

This is the beauty of open source. It defies this kind of corporate grab.

Not sure I agree (5, Interesting)

numLocked (801188) | more than 9 years ago | (#9903423)

I feel like Mr. Felton is looking for things to be wrong with PHP 5:

"There are private and protected members and methods, abstract classes and interfaces, in practice, identical to Java's object model."
A ton of languages treat classes like this. This is really pretty standard. The underpinnings of the way PHP handles classes may be like Java, which makes sense because Java does it pretty well, but as far as the developer is concerned, it's just like a host of other languages.

"companies whose coffers are already overflowing"
Sun's coffers are not exactly overflowing

"Java became successful for a reason: it's intelligently designed and facilitates code reuse."
exactly. why shouldn't php do the same?

"Instead of passing the actual object itself, PHP's object model passes by reference"
This has been deprecated for some time - most PHP developers knew this was coming and had php.ini configured to do this by default already. This has nothing to do with my point, but is an interesting side note.

"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"
oh come on. This is CS 101 stuff...how many serious PHP developers could there be who don't know that stuff?

I agree, he's fkin nuts (2, Interesting)

JVert (578547) | more than 9 years ago | (#9903549)

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?

I feel soo bad. I have used open source at my work and I have received financial gain through salary and the occasional bonus. AYE HE SAID COFFERS! Obviously promoting piracy.

not quite. (4, Insightful)

pb (1020) | more than 9 years ago | (#9903902)

The way Java handles protected variables (due to packages) is starkly different from the way C++ handles protected variables. Fortunately, it looks like PHP picked the (less broken, IMHO) C++ way to do it.

As for your final comments--all too many PHP developers don't know "CS 101 stuff", serious or no. Also, I know that when I first learned about the OO methodology, it was quite confusing. Now that I know more about it, I'm convinced that there's a lot there to be avoided, and all of it should be carefully considered.

Fortunately, (like the crippled "object system" in PHP 4) if you don't want to use it, you still don't have to use it.

Re:not quite. (1)

aled (228417) | more than 9 years ago | (#9906151)

The way Java handles protected variables (due to packages) is starkly different from the way C++ handles protected variables. Fortunately, it looks like PHP picked the (less broken, IMHO) C++ way to do it.
Would you elaborate on this?

Re:not quite. (2, Informative)

Tim[m] (5411) | more than 9 years ago | (#9907638)

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.

Re:not quite. (1)

aled (228417) | more than 9 years ago | (#9908479)

I have found this: "The protected keyword has a similar meaning to that in C++, but protected entities are also accessible in all methods of classes in the same package."
It don't see much of a problem here.

Re:not quite. (1)

gedhrel (241953) | more than 9 years ago | (#9919517)

Argh. This is inaccurate.
Here's a link:
http://java.sun.com/docs/books/jls/second_edition/ html/names.doc.html#104285 [sun.com]

In a nutshell (and paraphrasing)

public members have global visibility.
private members are visible solely within the top-level class that declares them
default-access members have package visibility
protected members have package visibility AND are visible to subclasses.

yep, that's it! (1)

pb (1020) | more than 9 years ago | (#9921281)

Also, in Java 1.0.2 there was a "private protected [sun.com] " keyword that corresponded to C++-style protected variable access. However, apparently that was a "bug", and was quickly removed, over the protests of the userbase.

P.S. sorry I didn't reply in this thread earlier to clarify things, guys, I guess I didn't think anyone would be interested. :)

Re:not quite. (1)

Tim[m] (5411) | more than 9 years ago | (#9927133)

There is an incorrect statement, caused by an error in my original test. I updated my test [american.edu] , and the last line should read

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

Your last comment (protected members have package visibility AND are visible to subclasses) helps explain the discrepancy betweeen foo.WonkPrime and bar.WonkPrime: there are two distinct access rules in play. The package visibility rule (which only applies to foo.WonkPrime) allows foo.* to access any protected member in any instance of foo.Wonk. The subclass visibility rule allows bar.WonkPrime to access protected members inherited from foo.Wonk. (For me, it was helpful to think that "protected members inherited from foo.Wonk" != "protected members in foo.Wonk")

There is order in the universe, and I'll stop wasting everyone's time now. :)

Re:Not sure I agree (1)

LWATCDR (28044) | more than 9 years ago | (#9908366)

When I took CS 101 there whre no stinking methods! It was structured programing! The way real programers work!.
Actually I look forward to playing with the new PHP 5 I just worry that it might break a lot of stuff like PHP-Nuke.

Re:Not sure I agree (0)

Anonymous Coward | more than 9 years ago | (#9909676)

It was structured programing! The way real programers work!

Nonsense. Real programmers have been doing functional programming since Lisp first came out, although these days they tend to prefer something with a more sophisticated type system like Haskell or an ML.

Structured programming is for code monkeys. And before anyone mentions ASM, that's just for l337 d3m0 sk3n3 d00ds who believe that cock size is inversely proportional to code size.

The Gnome/IBM argument. (0)

Anonymous Coward | more than 9 years ago | (#9903502)

"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?"

This is the gist of your argument. Now substitute any open-source software of your choosing. Has the argument changed? Better, or worse? Why is PHP any different than any other FOSS?

PHP and MySQL? (3, Interesting)

Unordained (262962) | more than 9 years ago | (#9903533)

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.

Maybe you don't realize this, but PHP supports quite a range of database products. The fact that it seemed to favor MySQL over the rest didn't really help anything; it just made more people use a product they wouldn't necessarily have chosen on its own merits alone, and directed more programming/bug-fixing toward that one product. Postgresql or Firebird, SAP or Oracle ... you have plenty of choices, and fast development doesn't depend on MySQL. In fact there are problem domains where MySQL slows down development because of lacking features. It's something to consider. Unless PHP drops all support for database operations, it'll remain useful for these kinds of applications. There's no reason to give up hope!

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. It cleans everything up, and leaves us with obvious choices to be made.

Re:PHP and MySQL? (3, Informative)

Electrum (94638) | more than 9 years ago | (#9904571)

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 and MySQL? (1)

Unordained (262962) | more than 9 years ago | (#9905891)

... actually, that's not always been the position (vague) of the FSF. it's been -also- said that dynamically linking with a library is the -same- thing as statically linking, thus making it subject to the same rules. sure, it's debated, and sure, it's never been tested in court. but it's not as clear as you would like it to be.

if you want your stuff to be usable, make the client libraries LGPL. period.

Re:PHP and MySQL? (1)

Electrum (94638) | more than 9 years ago | (#9907437)

actually, that's not always been the position (vague) of the FSF. it's been -also- said that dynamically linking with a library is the -same- thing as statically linking

It doesn't matter what the FSF thinks. What matters is copyright law. Unless dynamic linking is a violation of copyright law then the GPL doesn't apply. Remember, the GPL is simply a conditional copyright waiver.

Of course, it's obvious that dynamic linking is not a violation of copyright law. Do a Google search and you'll find stuff like this [brouhaha.com] . Or simply use your head.

Re:PHP and MySQL? (2)

Christopher Cashell (2517) | more than 9 years ago | (#9905339)

This reminds me of a question I've wanted to see answered for such a long time now. . .

Why isn't there a standard Database Independant Interface library yet?

There's been all this talk about the "new MySQL" crap, and that's nice an all (if you're a MySQL user), but I don't care about MySQL. What I do care about, is writing applications that are as portable as possible across databases.

With a little bit of work, it isn't that hard to write code that will work well across PostgreSQL, Oracle, and MySQL. . . at least, in Perl it isn't. Perl's had the extremely well done DBI library for years. So why has PHP repeatedly dropped the ball and not done something similar? Why do we have to go to third-party libraries (ADODB) to get something that should be a fairly standard part of the base language libraries?

There are tons of great applications out there written in Perl that can be made to work with almost any database that DBI supports, with minimal work. At the same time, there are tons of PHP applications that will work with. . . MySQL. And that's it.

When PHP4 was released, I had hopes that they'd wise up and take care of this. The closest thing was the PEAR DB class, which never really took off (and is considered to be inferior to ADODB by most people I know). In fact, the whole PEAR thing seems to have suffered from lack of direction, lack of documentation, and a very poor job on the part of the people behind it to explain what it is, and why people should care. Now PHP5 has come out, and we're still in the same boat as before.

Consider this. . . when was the last time you looked at a Perl application that *didn't* use the DBI library to talk to the database? Can anyone even remember any Perl applications that talk to the database directly?

Neither can I.

Re:PHP and MySQL? (1)

chromatic (9471) | more than 9 years ago | (#9905414)

Why isn't there a standard Database Independant Interface library yet?

For PHP? I suspect it's because the language has built-in MySQL access functions from the start, at least in the most common configuration. It's so easy to start using MySQL with PHP that there's really no reason an alternate access mechanism could gain any significant traction.

This is one of several cases in PHP where attempting to simplify the language for novices has made some tasks much more difficult. It's a pity that namespaces didn't make it into PHP 5.

Re:PHP and MySQL? (1)

Christopher Cashell (2517) | more than 9 years ago | (#9907030)

Yeah.

Unfortunately, it's a royal pain in the butt when you're a developer who does their development on PostgreSQL, and their deployment on Oracle and DB2. We've had to spend way too much time dealing with database issues because of the lack of a standard database independant interface.

Much as I'd prefer using PHP, we've actually ended up having ot use Perl for a number of projects, simply because it reduced the headache and development issues so much.

Oh, well. Maybe with PHP6, they'll pull their heads out of their butts long enough to fix this issue.

Re:PHP and MySQL? (1)

rycamor (194164) | more than 9 years ago | (#9929054)

PHP has had a database abstraction library as a loadable/compilable extension for years (dbx [php.net] ). It has a very small function list, which I consider a strength rather than a weakness, since it allows everything actually needed to interact with an SQL DBMS. I personally really like DBX, and wish it was always enabled by default.

Also, PHP 5 has a new abstraction library which is available in PECL, called PDO [php.net] .

Yes, I know these are not enabled "by default", but given that Perl's largest DB abstraction library is also a module, rather than a core component, any complaint vis-a-vis Perl/PHP DB abstraction is moot.

Zend vs Rasmus (4, Interesting)

TekZen (611640) | more than 9 years ago | (#9903535)

Zend has done a really good job of positioning themselves as the apparent "leaders" of PHP. However, Rasmus recently was quoted [technetra.com] as saying:
Over the years PHP has grown from a single guy, me, to now 800-900 people around the world contributing.
I read that comment as a jab at Zeev and Andi. I think there is a power struggle going on, but Rasmus' point is a good one.

The PHP group is 9 guys across the globe. Zend is a strong force and helpful. I like the syntax changes that make PHP more like Java, but I don't want to see any company own PHP.

Luckily, it's not gonna happen.

-Jackson [jaxn.org]

Re:Zend vs Rasmus (0)

Anonymous Coward | more than 9 years ago | (#9927382)

Keep that FUD coming!

Yeah, Right! (2, Funny)

pats (39583) | more than 9 years ago | (#9903561)

Get a grip on yourself man. It's Friday - go out & have a few beers.

Besides, you missed the real threat: Given the similarity between PHP 5 & C# object models, it's obvious the evil empire is trying to take over PHP (or maybe Sun is trying to control C# as well).

eerie similarities... (1)

Roman_(ajvvs) (722885) | more than 9 years ago | (#9909042)

I thought it was obvious that everyone wants to look like Java... but then java is supposed to look like C++.. which in turn looks like C (or is it C that looks like C++?).

As OO languages go, there will always be similarities in implementation. Having needless variation in the what the time function is called (for instance) isn't in anyone's interest.
There are relevant differences in underlying code compilation and running, but when it comes to writing.. a language == a language = a language := a language.

It's all just syntax in the end.

Evil Plot? (3, Interesting)

cornice (9801) | more than 9 years ago | (#9903586)


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?


A - Which of these companies have overflowing coffers?

B - It's open source. If someone wants to contribute then they can contribute. If someone wants to profit then they can attempt to profit. I don't see why a company that contributes shouldn't have the opportunity to profit somehow.

C - Nothing says that PHP can't be forked back towards the little web scripting engine that was once PHP and PHP/FI before that.

Too many futures (4, Interesting)

Spooker (22094) | more than 9 years ago | (#9903615)

5 years ago no one had heard of PHP (ok, a bit of exaggeration since I started with PHP 7 years ago) ... and it has grown from the niche geek toy into something the big boys play with ... it started as a small project of one person and now it has tens of books written about (many translated to multiple languages), 3 specific magazines, numerous companies providing commercial tools, more companies providing development support and women who think it's sexy (I know she's out there, where are you?) ...

It's nice to know where the OO model comes from, gives it more credence ... it's nice to know that the larger companies are taking notice (even if one of them may be grasping at anything to stay alive) ... and yes Zend can be considered to have a large say in what direction PHP takes (I will not propogate rumors, I will not propogate rumors) ... but what about looking at the history of Perl as a possible role model for PHP? Didn't that also get slammed with rumors of corporate takeover when ActiveState started doing more with it? Notice that Perl is still OS ...

Is talking about Sun, Macromedia and MySQL horning in on the action is like chicken little proclaiming the sky is falling ... or is this a wakeup call to the PHP programming public to take back their rights that have been trampled on by so many trying to take commercial advantage of a language by the people for the people?

Food for thought ...

p.s. I work for a company that produces commercial tools for PHP development :)

PHP5 from Java? (2, Funny)

vf123 (244292) | more than 9 years ago | (#9903648)

While PHP5 is very similar to Java I believe it's mainly the shift to object orientated programming that brings the 'cloning' that you see.

That and a dash of paranoia.

Growing a Language (4, Insightful)

Ridgelift (228977) | more than 9 years ago | (#9903764)

What drives me crazy about PHP is it just keeps growing. Need another function? Ah let's just add it! The problem is the language grows from something quite simple to something that's impossible to master.

I like the approach Python has taken. Everything is kept clean and simple, and the complexity is added through importing modules. Need another function? Import it! I guess that's why Python is said to "fit in your head".

I'd better stop before I start a flame-war. The point I wanted to make is PHP and Java will both probably collapse under their own weight, and another simpler language will take their place. If the plan is the grow PHP into Java, then there will be tonnes of books needed to reference everything, which is good if you want to sell books, but bad if you want to write programs without having to constantly look something up.

It seems to me that a programming language needs to plan for growth before it starts, otherwise it grows and gobbles up the mental resources of the programmers using it. Once it's too big, people will just fall back on simpler tools.

cruft (5, Interesting)

pizza_milkshake (580452) | more than 9 years ago | (#9904118)

agreed, the more i work with php the more i dislike its interface. there is no standardization of function names, as illustrated in strtoupper() and str_split(). nor are arguments in a standard order, such as in_array(needle, haystack) and strpos(haystack, needle). some functions are horribly named, see the aformentioned strtoupper(). and there's just something about having several hundred (maybe thousand?!) functions in the same namespace. every other popular scripting language i know has the concept of modules, allowing subsets of functions to be imported and used when necessary... there's pear, but it's certainly secondary to php itself and not nearly as widely used within php as perl is within cpan.

now don't get me wrong, i'm not bashing php. i use php all the time and it is a pretty straightforward tool and quite easy to pick up. the inevitable problem with trying to reform a language is that you need to "break" it in order to fix it

Re:cruft (4, Interesting)

cyberkreiger (463962) | more than 9 years ago | (#9904317)

According to http://tnx.nl/php [tnx.nl] there are 3079 core functions in PHP4 (as of november 2003), compared to 206 in perl.

Re:cruft (1)

Theatetus (521747) | more than 9 years ago | (#9907183)

there are 3079 core functions in PHP4 (as of november 2003), compared to 206 in perl.

Or 7 in Lisp.

Re:cruft (3, Funny)

Anonymous Coward | more than 9 years ago | (#9907493)

> > there are 3079 core functions in PHP4 (as of november 2003), compared to 206 in perl.

> Or 7 in Lisp.

7 core functions and 3072 interpretations for the character ')'

Not 3079 (1)

mgkimsal2 (200677) | more than 9 years ago | (#9908183)

3079 is only if you compile in every single possible external module. Most people aren't going to compile in mssql and mysql and oracle and pgsql and msql support at the same time, for example. Anecdotally, having worked across dozens of installations in various shops large and small and numerous hosting environments, there's probably 1000 functions that are commonly available via 'standard' compiled-in modules (mysql, gd, odbc, imap, etc).

Re:cruft (3, Insightful)

Ridgelift (228977) | more than 9 years ago | (#9904683)

now don't get me wrong, i'm not bashing php. i use php all the time and it is a pretty straightforward tool and quite easy to pick up. the inevitable problem with trying to reform a language is that you need to "break" it in order to fix it

In the movie "City Slickers" Jack Palance's character quips that the secret to life is just one thing, and once you know what that one thing is, everything else makes sense. I'm beginning to think that programming languages are the same way. The "one thing" about Visual Basic was introducing components. Perl's one best thing is powerful reporting capabilities. Python's contribution is namespace (just type 'import this' into the interpreter for an easter egg's explanation).

PHP's "one great thing" seems to be initial ease of use. It's dead simple to install, the php website's documentation is second-to-none, and it's relatively painless to cut-and-paste code inside HTML to make stuff work. My problem, however, is the same complaint I have with the Windows operating system: PHP is impossible to master, because it's becoming too broad with too many functions and too many special cases.

According to http://tnx.nl/php [tnx.nl] there are 3079 core functions in PHP4 (as of november 2003), compared to 206 in perl.

3079? That's just seems insane to me.

PHP's "one thing" (1)

Dr.Dubious DDQ (11968) | more than 9 years ago | (#9904984)

I would argue that PHP's "One Thing", in this case, would be it's ability to handle a variety of different types of data streams with a single simple set of functions.

Data from webservers, ftp servers, files, named pipes, and network sockets can all work more or less the same way. I find it nice to be able to talk to network servers with it just as easily as I can read and write plain files.

Re:cruft (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#9909698)

The "one thing" about Visual Basic was introducing components. Perl's one best thing is powerful reporting capabilities. Python's contribution is namespace (just type 'import this' into the interpreter for an easter egg's explanation).

Uh, do you have a clue what you're talking about?

Components were introduced in Smalltalk, about twenty years before VB. Perl's reporting capabilities are better than anything that came before, but they're nothing new, it all already existed in string processing languages like awk and SNOBOL. And namespaces existed all over the place before Python.

Re:Growing a Language (2, Insightful)

AuMatar (183847) | more than 9 years ago | (#9904656)

Except that the standard library!= the language. You do not need to memorize know all the functions in it. I don't even know the full C standard library, at its piddly 100 or so functions. Hell, you don't even need to know that the standard library exists, you can program without it.

As for Python and importing vs Java/PHP- the two ideas are exactly equivalent. If you're going to import it, you need to know it exists, which means you did as much reading/memorizing as everyone doing Java/PHP. If you didn't, you'll end up writing the functionality yourself.

Now, I have my own issues with standard libraries. I think they inhibit innovation, and a Perl style web depository of libraries is far better. That lets implementations evolve and compete so better ones emerge. But if you're going to have a standard library, the difference between the Java and Python methods is zero.

Re:Growing a Language (1)

salimma (115327) | more than 9 years ago | (#9912414)

As for Python and importing vs Java/PHP- the two ideas are exactly equivalent. If you're going to import it, you need to know it exists, which means you did as much reading/memorizing as everyone doing Java/PHP. If you didn't, you'll end up writing the functionality yourself.

Not quite; if you use a decent IDE with code completion / code assist / whatever, having namespaces really help in pinning down that function you need, e.g. if you need a string function, it's easy to just type string. , press CTRL+Space, then scroll through the string functions till you find the one you want.

With a standardized naming system, this could work with a ton of functions in a flat namespace too, but hard to enforce.

Re:Growing a Language (1)

AuMatar (183847) | more than 9 years ago | (#9918077)

Agreed, a naming convention is a good thing. That still doesn't make the Python idea of importing from a massive standard library any different from PHPs just use the function method.

As for the IDE- eh. I find those autocomplete and the like really damn annoying. A language should be built to be tool agnostic, not pick and choose ways of doing things based on the currently available tools. Do it that way, and it'll end up being completely unfit for the tools of tomorrow.

Re:Growing a Language (1)

salimma (115327) | more than 9 years ago | (#9935723)

A language should be built to be tool agnostic, not pick and choose ways of doing things based on the currently available tools

Tools like Eclipse allow the use of plug-ins to support new languages, so provided the language you want to use is not too esoteric (or you are willing to get dirty and write a plugin), code completion should just work. AFAIR Eclipse, with the appropriate plug-ins, could indent and code-assist Java, C, C++, C# and Python, and I'm sure I'm missing some.

Re:Growing a Language (1)

letalis (570718) | more than 9 years ago | (#9908872)

I have a hard time seeing why this is a problem from a developer of PHPs point of view. You use the functionality you need, there is no need to know everything about the rest. If you need it but don't know it, hey, that's what the thoroughout documentation is for.

I think the "clean and simple" with complexity in modules is just a problem if you try to think of it. If you consider the "core functionality" of PHP it is quite easy to see what really is core and what is not. The distinction is made by you as a developer.

If you need functionality X from module Y you still will have to know that it exists. And if it doesn't exist because the language is so simple, then you will have to have the knowledge to develop it yourself, hardly something that makes it easier to master. So the complexity of languages that can do the same should not differ much in my opinion.

As a side note: If your foretelling about that Java and PHP will collapse under the weight of their respective base libraries is correct then it should certainly happen to .NET. I find it a bit hard to believe that the three largest languages of the net/coporate world would end their days by such a reason.

The beginning of the end for PHP? Good riddance. (0, Flamebait)

Flumph (58891) | more than 9 years ago | (#9903778)

Grown from a toy language with one neat trick -- a big switch that you throw between "write this to stdout" and "interpret this as code" -- PHP is yet another language whose only reason for existing is to indulge the coders' desires to play with the new shiny toy. (TCL, Python, etc.)

All scripting languages move toward feature-parity with perl. Why bother with that process? Let the toy remain a toy.

Rather than reiterate language design from 10 years ago, why not just use an existing tool to do something new and useful?

Yeah, perl's syntax is arcane, but it's powerful. Yeah, the language is huge, but is it better to implement a smaller language that is then expanded over and over?

Curmudgeonly yours,

Flumph

duh (4, Insightful)

Sparr0 (451780) | more than 9 years ago | (#9903885)

Keep using PHP4 or PHP5 if you dont like where Zend/Sun takes PHP6. Its not like features will start to magically disappear from the old versions.

Re:duh (1)

mlinksva (1755) | more than 9 years ago | (#9904397)

PHP6? Nah, with Sun involved, the next version will be PHP10 and the version after that PHP10 Platform Standard Edition 50.

PHP needs to be re-implemented under GPL or BSD (0)

Anonymous Coward | more than 9 years ago | (#9904092)

If there are any problems with PHP, it will be forked. Or rather, rewritten, because the PHP license includes a rather obnoxious trap door:

6. The software incorporates the Zend Engine, a product of Zend Technologies, Ltd. ("Zend"). [....] In the event that you separate the Zend Engine (or any portion thereof) from the rest of the software, or modify the Zend Engine, or any portion thereof, your use of the separated or modified Zend Engine software shall not be governed by this license, and instead shall be governed by the license set forth at http://www.zend.com/license/ZendLicense/.

I haven't looked at that URL because it's an URL: it can change at any time.

I have always been concerned about the tight interaction between PHP and Zend. For instance there is still no free and *reliable* bytecode compiler available for PHP, and the maintainer of the most promising accelerator has been "taken off the street" (hired) by Zend.

I do believe this article is a minor dose of FUD but I also believe someone *needs* to re-implement PHP based only on the specification and release the code under the GPL or the BSD license, rather than a made-up pseudo-BSD Zend-friendly license.

Re:PHP needs to be re-implemented under GPL or BSD (5, Informative)

andig (139527) | more than 9 years ago | (#9906826)

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

So, Zend was good, and SUN & Co are bad now? (1)

PaulBu (473180) | more than 9 years ago | (#9904252)

Zend, the Israeli company backing the development of PHP...

As far as I understand from your review, PHP development was directed not by a non-profit (think Apache Foundation), but by a business (think MySQL and Zope) for a while now, and this was OK from your POV until some bigger businesses offered investment in Zend. Can you reasonably justify (at least to yourself) why Zend was OK and "Sun, MySQL, Borland and Macromedia" are bad-bad-bad corporations? Especially since MySQL could not be MUCH bigger, right?

If there were a Microsoft connection, I might don on my tinfoil hat (not just because they are BIG, but because of their monopolistic practices).

Paul B.

Re:So, Zend was good, and SUN & Co are bad now (1)

aled (228417) | more than 9 years ago | (#9906214)

I don't what the Sun interest would be in PHP given that Java has Servlets/JSP that could be seen as a competing techonolgy.

Corporate Shill Indeed... (1)

rlanctot (310750) | more than 9 years ago | (#9905853)

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?


It seems to me that the situation he's describing here is much like RedHat 'shilling' Linux for profit. Now, of course, I recognize that Linus et al aren't part of RedHat, but the end effect is the same, really, just further down the timeline.

PHP is at the state right now where Linux was before people started forking off various distros.

I'm not particularly concerned that PHP will become 'commercialized' any more than I am that Perl is 'commercialized' by ActiveState. The language and the community is more than the sum of a few key people, or even companies involved. The community around it is the main strength, and it's that ubiquitiousness that's the core of PHP, not the language itself.

mod story down as (1-,Troll) (-1, Flamebait)

mike_sucks (55259) | more than 9 years ago | (#9906198)

Is the a way to mod a story as a troll? This one sure as hell is. Look, I don't know exactly what license PHP uses, but unless it it some fruitcake that the PHP people can retroactively revoke for all versions, who cares if Zend is partnering with Sun?

PHP is getting more exposure, features and deployments? And you're complaining? Christ! If you don't like 5, keep using 4. If you don't like writing OO, write your same old procedural code!

And what if it is owned by Sun? Exactly what is the problem with that when it is effectively owned by Zend right now?

It sounds like some anti-Java zealot got their nose out of wack because a few Java-like features are in 5, or maybe you have some personal axe to grind about Zend, Sun or MySQL Inc for some reason.

Stop whinging and pull your head in, Ian Felton.

No Such Evidence (2, Insightful)

Tablizer (95088) | more than 9 years ago | (#9906823)

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...

For years I have been asking for concrete examples of OO producing code reuse in the business domain, but have yet to see a convincing example. OO does NOT have objectively demonstratable magic properties (except in a few narrow conditions that I don't encounter very often).

Some people pick OO because they personally like it, NOT because it is objectively better. Enough with the OO hype.

Re:No Such Evidence (1)

CoolGuySteve (264277) | more than 9 years ago | (#9907120)

With Java, pretty much anything you'd want to reuse is already included in the massive standard library, simple stuff like ArrayList and TreeMap come up every day. Java's Object hierarchy itself is an excellent demonstration of code reuse. Because of the massive library, the code you do write yourself will probably be customized to whatever you're doing. That's a good thing.

On a less bloated front, I often write objects into a test harness before dropping them into a large project. This allows for easier and more thorough testing. When I do implement them, I'll be certain that they won't conflict with other names and that they work the way they're supposed to.

By properly using interfaces, I can also tear down what I wrote and reimplement it without having to change the rest of the code. So I can write just enough to get things off the ground, then go work on other things. For data structures like priority queues and whatnot where a grossly inefficient solution can be written in minutes, this is essential.

This stuff can be done in C with header files and strict naming policies but it's a lot more painful.

Re:No Such Evidence (0, Offtopic)

Tablizer (95088) | more than 9 years ago | (#9907527)

With Java, pretty much anything you'd want to reuse is already included in the massive standard library

Perl and Common Lisp also have huge libraries. How does OO make it better?

I often write objects into a test harness before dropping them into a large project.

Functions, modules etc. can do the same.

By properly using interfaces, I can also tear down what I wrote and reimplement it without having to change the rest of the code.

Functions and declarative interfaces are also black boxes.

This stuff can be done in C with header files and strict naming policies but it's a lot more painful.

C is hardly the pennacle of procedural and declarative programming. Please don't use C's faults to bash every other non-OO paradigm/language.

Re:No Such Evidence (0)

Anonymous Coward | more than 9 years ago | (#9907151)

"For years I have been asking for concrete examples of OO producing code reuse in the business domain, but have yet to see a convincing example. OO does NOT have objectively demonstratable magic properties (except in a few narrow conditions that I don't encounter very often)."

A major problem is that management decrees a change of platform before reuse can really be taken advantage of.

Before long, you're rewriting in something new because management has decided to move to Java, or .NET, or whatever. Or a merger has required that you throw out your system and adopt the one the other company developed.

Or the people who know what's there to be reused get laid off or quit, and the new people reinvent the wheel not knowing what's available.

Macromedia? (1)

School_HK (757129) | more than 9 years ago | (#9907314)

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.
ColdFusion, is a product of Macromedia. Is that the deal hiring advisors from Macromedia, or advisor itself is Macromedia?

Amazing similarities (5, Funny)

eric.t.f.bat (102290) | more than 9 years ago | (#9907531)

This guy only knows Java and PHP, and he's amazed at how similar they are. Me, I only know Latin and PHP, and I'm amazed at how similar THEY are! I predict that PHP will soon change its name to the Pompeii Hypertext Processorium!

Mod_Python/PSP is better (0)

Anonymous Coward | more than 9 years ago | (#9910923)

Why bother with the inconsistent mess that's called PHP, when you can plug mod_python [modpython.org] into Apache. With recent editions you can also write inline python code - just as PHP.

It all tastes better, run faster, is easier to learn and maintain.

does OSS help corporations or individuals most? (1)

h00manist (800926) | more than 9 years ago | (#9942690)

It's an interesting exercise to study just how much OSS is actually helping corporations, who already use it in one form or another, and individuals, people at home.

Especially those on the wrong side of the tracks, or the border lines, affected by the "digital divide".

I tried installing Linux for internet access on an old P5, just the way it was, without changing any hardware.

Winmodems are what the poor have. They don't work on Linux.
Ethernet is what corporations have. It works.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...