Introduction to PHP5

Yet Another OO Fanatic writes "PHP core developer Sterling Hughes has a excellent presentation (mirror) about PHP5 online. So far it seems to be the best coverage of the new features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions. Java by any other name..."

Comments

And, if you want it right now...

[oGMo]

And, if you want it right now, instead of waiting for PHP5, go get Ruby today. It's got all of this, and many more neat features. I've recently been moving PHP over to Ruby, because PHP wouldn't scale to a large project (taking 4-5 seconds to load and generate a page on a hefty server, the codebase was only about a meg and a half of PHP), and because it was incessantly segfaulting for mysterious reasons. I've had no such problems since.

And ruby's a lot of fun... you can use it for tiny scripts, sites, or large projects.

Re:And, if you want it right now...

[jasondlee]

Doesn't scale? I guess someone had better tell Yahoo.

jason

Re:And, if you want it right now...

[oGMo]

Those reasons are undebugged code. No app just mysteriously segfaults (mystery isn't allowed in computers)... if the code was correct, it wouldn't segfault. Might be something minor... and you might have poured over it a million times, but somewhere you're code was still wrong.

You're wrong. No script should cause the interpreter to seg, period. If there's an error condition, it should be reported. A segfault is a bug in the interpreter, no matter how buggy my code is.

Also, you're doubly-wrong, because statement reordering would sometimes alleviate the problem. Also things like calling get_defined_classes() (or whatever it was called) would segfault on PPC, but not x86. (This was fixed recently.)

Re:And, if you want it right now...

[oGMo]

Specifics are about the same. Little over 300 files total (only a small fraction of the complete system unfortunately), about 1.5 meg of code. This is not just a simple database interface, though. It's a complete persistant object system, widget framework, with object access controls, interface building, and the like. It makes development very fast, and lets me do things that would be very difficult with straight PHP (or anything else).

Unfortunately, when it came to building pages themselves, generating them from objects recursively was the final straw. The times really shot up, although they had been building for some time as the codesize and functionality increased.

With the new Ruby version, most of the processing, including building the pages, is moved to a backend server (written in Ruby), with a thin layer of CGI (in Ruby) that calls it. Loading the interpreter, parsing, calling the backend, processing, returning, and output is down to half a second on my old p2-350. And the capabilities are far beyond what the PHP version had (although, this was in part due to the fact it's a newer version, but some things PHP's object model would not have been able to handle, such as the integration of any given object, and adding syntax for class and method metadata).

Re:And, if you want it right now...

[sporty]

You don't know how yahoo uses php. It might use it on command line for generating static pages. So beware what you think they are doing. You never know.

Re:And, if you want it right now...

[oGMo]

Ah hem, but you're wrong. Well, a little bit right. No script should segfault the interpreter, but there's no good way I know of to keep the interpreter from segfaulting when the script makes calls to functions that drill down into shared libraries or .dll's.

There is an easy way. You catch the signal 11, and send an error to the script saying that something happened in the library that wasn't the interpreter's fault.

The interpreter should not just crash and return no useful output, like PHP was doing.

As long as something's in the same process it can take the whole thing down with an invalid memory access. I see it all the time in Java code using JNI to get at Win32 .dll's. It sucks, yes, but it's not the interpreter's fault.

Maybe in Windows this is the case, but not Unix, where you can catch a segfault and do a longjmp to an error handler. Tidy and easy.

Now, today I'm running a Java application under a web application server and the server would just die -- with no error message. Nothing, not a single line of output. It just exited, logging nothing to a file nor to screen. -THAT- is horribly unacceptable.

I completely agree. This is exactly what PHP was doing.

We need good examples

[phorm]

Hopefully... PHP5 will either address some of the common mistakes (without becoming brainless) or at least have some good example out there.

If anyone has noticed... one of the major areas of death/slashdotting of sites apart from bandwidth are php URL's... and/or mySQL queries (often on PHP URL's). I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

Now, I'm not sure if that's a faultof PHP itself, or that some of the "easier" features of PHP tend to attract less competent programmers and/or misconfigurations?

Re:We need good examples

[mshiltonj]

If anyone has noticed... one of the major areas of death/slashdotting of sites apart from bandwidth are php URL's... and/or mySQL queries (often on PHP URL's). I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

PHP will run in just about any hosted environment. It is nearly ubiquitous in any shared hosting package.

Machines used in virtual hosting packages (in the < $50 price range) usually have the web server and the db on one machine with less than a GB of memory, and have upwards of a couple dozen or more sites running on the same machine.

For many, if not most, sites, especially the non-commercial sites, this is more than necessary. They can be incredibly complex and completely dynamic sites. Such is the power of PHP, it puts great power into meager hands.

In meager hands, however, one quickly runs out of resources.

Perl, on the other hand, and more specifically mod_perl, isn't usually in these virtual hosting packages. Why? Because mod_perl really gets into the the guts of apache, and anything really neat requires non-trivial modifications to the httpd.conf file. (not just an .htaccess file)

Sites that use mod_perl, then, usually have thier own dedicated machines, and in those cases will usually have _multiple_ machines dedicated to serving a site.

For instance, Slashdot is run using 10 different machines.

You'll have to stress test PHP vs. mod_perl on like hardware before drawing any conclusions
about slashdot-resistance.

Re:We need good examples

[Arethan]

Slashdotting occurs mainly because 1 of 2 things happens. Either a) the pipe to the webserver is too small and the traffic overwhelms their connection; or b) the hardware falls behind in servicing the requests, and thus pages start failing.

Usually, it's b). Particularly, database queries being the main culprit. When people write database backended websites, they take 1 of two approaches. Make calls to the database every time a page is requested (most used), or they call the database for the first request, caching the result, and feed the cached copy to all other requests that occur within the cache's lifetime.

Method 1 is easier to do, but is flawed, in that you are placing all of the load on the database server. Once the requests start to pile up, it immediately becomes a bottleneck.

There was a nice write up about how some group put together a slashdot proof system, consisting of only modest Sun hardware. Their key was the use of java to run the website. Java allowed them to create system-wide objects that could be referenced by unrelated page requests. So they took method 2 in website design, and had a system that only made calls to the database when the cache didn't already hold a requested page.

PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects. Not even lowly variables. So you can pretty much bet that any stock webserver using PHP will not handle a slashdot link on it's own. It would need a caching server to keep the requests to the database at a minimum. Hopefully, PHP5 will fix this little problem, as even ASP allows for system-wide objects.

So the short answer to your last question is: It is the fault of the programmer for choosing the wrong model, but PHP doesn't give them any other option, making their only alternative to use a different language.

Hope that helps. :)

Re:new mysql

[Christopher Cashell]

I don't know that "almost everyone uses php+mysql+apache".

Personally, I much prefer php/perl+PostgreSQL+Apache. And I know I'm not the only one. Sometimes the most popular application isn't the best application (subject to your individual requirements, of course. . . but I've found PostgreSQL to be generally superior to MySQL for essentially all of my needs).

Oh, and subselects have been working great for me for years now. ;-)

Java? Hardly.

[Graelin]

Java by any other name...

Leave it to a Perl guy to compare PHP to Java.

features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions.

Of course, Perl has had all this for some time.

Just curious, how can you have an object model without namespaces? Or interfaces for that matter? Isn't that like "New Car - with tires!"??

Either way, PHP makes for a good interface language for web apps - I guess. You can throw it on top of an application layer to do the real work. Last I checked, you could only use SOAP to do this - has anyone tested how well that performs? SOAP doesn't scale all that well.

It would be nice to let the HTML monkeys handle some of this stuff while the serious development can take place in a real language. /me dawns the flamesuit.

Re:that thing was slashdotted with under 3 comment

[Chester K]

Either most slashdot readers are now actually reading the articles

It's a new feature of PHP5 ... Anticipatory Slashdotting.

Re:Java? Hardly.

[Fammy2000]

Wait. You don't have to pay extra for tires? =)

I'm still trying to figure out why I had to pay extra for floor mats.

Not doing much to improve my opinion... (/.'ed)

[tweakt]

The connection was refused when attempting to contact ny1.php.net

I tried to RTFA, and all I got was this lousy error message.

Nice and stable

[Bob Bobbinson]

From the blog :

PHP5 isn't ready

This is what I get for running a server on pre-alpha software.

Ok, so as many of you already know, I have my talk for NYPHP online. This talk is hosted on NYPHP's servers, and is running Apache 1.3.27 + PHP5.

PHP5 leaks worse than the titantic. With MaxRequestsPerChild at 100, apache children grew to 37MB (before we stopped counting). At MaxRequestsPerChild at 40, it was around 27mb. Finally, we've settled on a reasonable default 25 requests per child. MaxClients at 50.

This is a box that can easily handle 20 times this load. ugh.

PHP5 is pre-alpha. Don't think otherwise.

WORKING LINK (for now)

[Thoguth]

http://talks.php.net/show/php5intro

Not trying to karma-whore, I just thought I'd use my +1 for something good because nobody seemed to notice the AC link.

PHP Is *not* an application server

[tweakt]

In PHP, all you have are scripts. Sure they may be optimized, compiled, pseudo-object-oriented and even obfuscated... but they are still scripts. They may even include eachother. But they are still *SCRIPTS*.

After executing, they forget all knowledge. There is no persistence, no threading, no transactional support. All attempts to improve efficiency are afterthoughts and hacks.

At one point I tried to implement in-memory "application" wide shared data. The concept is, something may need to be loaded when the site is first loaded, and then it should be kept in RAM, and we need exactly ONE instance of it.

I gave up... using shared memory was too tricky and isn't even platform independent. It's not part of the core language, and even if it worked, it would not turn PHP into an application. It still runs in a modular fashion.

Now with a Java servlet, you have an application that is running. Within your servlet you may define some data exist indepently of web requests. Servicing a request is just one aspect of it. Its much more like a real program, which is why it're referred to as an Application Server.

For very simple things, that don't need to scale, both in usage, and codebase, then PHP is ok. But for design real web applications, which need to be managed by more than a few developers, integrate with legacy systems, implement a full three tier architecure, etc, PHP just doesn't cut it.

A lot of the bad sites which go down easily when /.'d are simply bad coding. Making 16 database accesses per page is not bad when just a few people visit at once, but when the stampede comes, your toast. Most people don't develop with that in mind.

Java has some serious strengths in the Web department, it's proven technology, and is not very complicated at all. It's just that most people aren't used to writing structured code. JAva forces you to follow somewhat good practices and the extra work pays off in maintainability. PHP and Perl you can just hack away, without any strong typing, etc and get something done very quickly but in the end it will become a mess quite fast.

I'm not saying Java will solve your problems, but there is a strong base of best practices, design patterns and example code to help you keep your code in nice shape.

With PHP, it seems like everyone has their own code libraries, utility scripts, ways of coding, etc and its really tough to resuse someone elses code. Java Interfaces and Inheritence comes in very handy.

Ok... enough ranting. Anyway, I used to be a hardcore PHP supported because you could whip together things very easy, but as I learned more java and needed to do larger projects and learned more about efficient coding, I realized with PHP you will eventually just run into a wall and that's when it's time to look for better solutions.

Re:PHP Is *not* an application server

[bahwi]

Best reason not to move to Java: click.

Programmers determine coding practices, structure, etc. You can find obfuscated java code, obfuscated python, obfuscated perl, or obfuscated php. It all depends on the _programmer_, not the programming language. It's like blaming car accidents on the type of car a person drives.

Structured code is a good thing though, and so is efficiency.

Most PHP Projects are put on a shared server, so using shared memory will generally anger the host. For enterprise level, maybe for a simple simple form I'd go with PHP, everything else I would go with something more hardcore, and yes, even Java. Java is a good language, but it's bad to be trapped to a single company for your language.

Mod_Perl on Apache does shared memory, along with several other improvements. With strict coding practices in a company, and someone going over the code(should be done with _every_ language and _every_ project) the code is easy to read, easy to re-use, and easy to modify. Yes, even Perl. High level enough to do things quickly and easily, and powerful enough to do it very quickly, using shared memory, etc.. Don't underestimate the power of mod_perl, it's easy to get a dynamic database page with mod_perl to load faster than static content.

And with mod_perl, and good practices(again, necessary even in Java) it will scale easily to multiple servers, legacy systems, etc...

Of course, we're waiting on Parrot. Yeah, kinda Perl 6, but yeah, it will compile Java. And yeah, cross platform, unlike Java (Java on BSD is a PITA, _and_ reminds me of Win 3.1 on my 33mhz system back in the day).

So again, the problem is the programmer, not the language. Although you are correct that PHP is not an application server. But look at Parrot and look at Perl, things can grow into even better things.

Parrot also has a BF (Brain****) interpreter.

Re:PHP Is *not* an application server

[Dalroth]

I was going to provide a quick and simple response. Then I decided to not get involved. Then I reread your post and couldn't help myself.

I'm going start out by getting to the point: Java is not the answer to everything. Not everything should be judged using Java as the standard. And finally, PHP is good enough for yahoo? Seems so: http://news.com.com/2100-1023-963937.html?tag=lh

In the interest of full disclosure: I am a full time senior level architect/programmer for one of the largest mortgage companies in the country. Most of the work I do is C# with an XML+XSL frontend these days. I won't touch any Microsoft product for my own personal projects, so in my spare time I do a lot of C++, Ruby, Perl and PHP work. I've long since given up dealing with Java, although there are Java projects (such as Struts, Cocoon, and JBoss) that I deeply respect.

I don't even like PHP, but it gets the job done. It gets it done far quicker and far easier than Java and most other languages, and I've long since learned that worse is often better (ask the Lisp community if you don't know what that phrase means).

To start, I want to point a major flaw in your arguments: Most of these PHP sites are written by amateurs plain and simple. Even a lot of the bigger PHP projects on freshmeat are clearly created by people who do not have a wealth of knowlege, but in it's place have a lot of dedication. That's fine. In fact, that's the way it should be.

The web was built via the back breaking work of millions of amateurs around the world. These people have just as much right to participate in this medium as us professionals do. Without them the web would be a desolate wasteland of holier than thou illuminati. Instead it's a rich and beautiful medium of communication supported by everybody.

"I gave up... using shared memory was too tricky and isn't even platform independent. It's not part of the core language, and even if it worked, it would not turn PHP into an application. It still runs in a modular fashion."

Why aren't you using the session? PHP has supported sessions for sometime now. There's no reason for you to be touching shared memory in a language like PHP. Would you do the same in a JSP page? I think not... Maybe you have your reasons, and PHP session handling is certainly not perfect in all situations, but your lack of an explanation as to what you are doing leads me to believe you either did not explore all possibilities, or you are making judgements based on older versions of PHP that are simply not valid anymore.

For very simple things, that don't need to scale, both in usage, and codebase, then PHP is ok. But for design real web applications, which need to be managed by more than a few developers, integrate with legacy systems, implement a full three tier architecure, etc, PHP just doesn't cut it.

Please excuse my english: 3-tier architectures are overrated overrused bullshit. Everybody has a different meaning for them, everybody has a different use for them. The only successfull n-tier architectures I have seen (and this comes from years of distributed COM+ development experience) are those that follow this structure:

Client -> Provider -> Scarce Resource

Where client is typically the web browser, the Provider is typically your web server, and the Scarce Resource is typically your database.

Breaking that into more tiers is imho absolutely foolish. The extra code complexity introduced, the marshalling overhead, latency overhead, thread synchronization issues, deployment issues, and security considerations are simply NOT WORTH IT! Why? Because the ONLY thing that really matters in the long run are your scarce resources!! That's your database! If you minimize calls to your scarce resources, you will get MUCH better bang for your buck than through any other medium. You can always throw some smart caching in there somewhere, but caching is NOT the same as adding an extra

Re:PHP Is *not* an application server

[Synn]

The "a scripting isn't a REAL programming language" arguement is as tired as it is old.

I started with Java back when the only IDE out was Symantec's Cafe(not Visual Cafe) and frankly over the years I've found myself to be most productive using scripting languages like perl and php.

They get things done faster with less code needed to be written in a world where fewer lines of code typically translates into fewer bugs and more productivity per programmer. And I can code in any amount of structure into a project as I see fit.

Now if I worked in a huge corporation where any idiot could submit code into my project, then yes a language that forces your hand could very well be a good thing.

But in skilled hands things like strong typing and forced OO really only get in the way.

Re:LAMP ... what about JOLA

[MmmmAqua]

Here's what I think...

I work for a company that uses both systems - LAMP for webservers, PJOLA (PHP/Java/Oracle/Linux/Apache) for the internal office/admin/order system, with some interesting interactions between the two systems.

For example, product data and changes originate in the internal system, get sent from Oracle to a MySQL master DB through an ODBC link, then the MySQL master propagates the changes down to the webservers, which are MySQL slaves. The flow of orders from MySQL to Oracle is less complicated, as each webserver transfers its orders directly to Oracle through an ODBC link.

These are just two of the interactions with external data involved in our system (data external to Oracle, that is). Here is why we don't use MySQL internally:

It's not ready for enterprise use. Flame me all you want, but that's the simple truth. Without subselects, built-in OLAP, a comprehensive data dictionary (which is crucial for system auditing), comprehensive tracing features (ditto), hot-standby failover support, clustered database support, and a dozen other things, MySQL is not suited to mission-critical environments.

It's fine for our webservers, where it is important to have a lightweight, fast database server, but not for the really important stuff; I can lose a webserver, no problem - there are several more I can redistribute the load to - but I absolutely cannot lose my office/order system. MySQL can't provide a reasonable guarantee of my data's integrity and security, so I'm not using it.

As for PostgreSQL - when we first started developing our system, we came down to two databases for the internal side: Oracle8i and PostgreSQL. We ended up choosing Oracle for performance reasons, and for clustered database support. PostgreSQL is a full-featured, stable, capable database, but it can't keep up with Oracle for speed or features. Example: Oracle9i's XMLDB - a huge boon to systems which do a lot of business-to-business (sorry, but I hate the B2B B2C, etc. crap) data interchange. Much of today's interchange is done in XML, and the ability to treat an XML file as just another table is a huge effort and timesaver. Oracle isn't the only database with XML support, but it is the only one I know of that allows you to join an XML file to an internal table for queries.

So, flame away, I'm wearing my asbestos underpants. But those are the facts as I see them.

Re:yikes!

[joab_son_of_zeruiah]

And what's with the java comment, PHP is pretty much nothing like java. ...

I understood the sense of this remark to be more about the PHP's and Java's capabilities to access other software systems, rather than a comment strictly about the language. Check out the PHP reference manual. Sure, the language is the first few chapters. Then check out the other *100* chapters.

One of the things I find fascinating when I compare the two at a system capability level is that they are equally capable. It's just that PHP is so much more easy to use, whereas Java is so much more orthodox. Easy to use often wins over orthodox.

In the long run PHP has as much chance to be a Java killer as .NET does. In the great battle for free vs. proprietary software do I really need orthodox?

Re:Where is the unified database interfase ?

[Christianfreak]

It does of course it still sucks, its not near as powerful as Perl's DBI but its a start and its much better than stupid_function_names()

Re:Where is the unified database interfase ?

[Monkey]

Have you ever seen the IBM commercial where the engineer shows up to a board meeting and he's got this big ball of connnectors and dongles and shit all connected together? It goes something like this:

CEO: What's that?
Engineer: It's a universal adapter for everything.
CEO: Everything?
Engineer: Yes anything, we've built in support to connect to all possible interfaces.
Executive Peon#1: Does it support European outlets?
Engineer: Umm... <looks at device in dismay>

Scale

[Synn]

I'm not too sure what kind of system/traffic your site had, but our company runs web-based apps for over 40 insurance agencies across the US.

We have one server that hosts 42,000 lines of PHP code and sees around 1300 insurance agents each day who log in, generate term/ltc quotes and download forms.

Most of the above code drills into a seperate MSSQL database server running Win2k, which actually has become our only bottleneck. That server fails rarely during very high traffic.

Locally the web server also sports a MySQL database server instance which hosts a little under 5 megs worth of rates for Long Term Care quoting.

For Term Life quoting I pull in a 50-200k XML datastream from an outside vendor.

The server hosts 1.7gigs worth of downloadable insurance forms.

All of this runs on a 1Ghz Pentium 3 with a half gig of ram. A good 300 megs of that ram is currently free.

In the three years this has been running I've yet to see php cause a crash in apache.

I'd say it scales pretty damn well.