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

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

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

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