Slashdot Mirror
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..."
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.
Topher
An afterthought that they decided to base an entire re-write of the core PHP engine around....
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.)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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.
The requested URL
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*.
/.'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.
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
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.
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.
Arr! The laws of physics be a harsh mistress!
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.
.htaccess file)
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
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.
Software Wars
I am waiting PHP can get something like that !
It's called PEAR DB and it already exists... Although, admittedly, it's not nearly as slick as JDBC and not quite as powerful as DBI.
Just curious, how can you have an object model without namespaces? Or interfaces for that matter? Isn't that like "New Car - with tires!"??
Plenty of OO languages do not have namespaces. It isn't vital to an object system in the least. They are handy, but far from neccesary.
Last I checked, you could only use SOAP to do this - has anyone tested how well that performs?
Last you checked, you could only do what with SOAP? RPC calls? from PHP to anything else? There are plenty of ways to do something analogous to SOAP, homebrew and pre-built, text (like SOAP or XML-RPC) or binary based.
(not that it matters, but you are donning the flamesuite, not "dawning" it.)
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
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.
I completely agree. This is exactly what PHP was doing.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
>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?
When did you last check, PHP3? PHP has had a Java binding, a Corba binding, and a COM binding for years (since early PHP4). And you can extend PHP with C if you need speed (rather than a more robust OO environment), you can even write your c code inline with php (see Inline_C) for a cool pear package.
The added OO features (and more importantly for speed matters, the fact that objects are now passed by reference and not by value by default) are just going to be a bonus. Exception handling will be nice for large projects.
>Just curious, how can you have an object model without namespaces? Or interfaces for that matter?
The objects in PHP where initially just glorified arrays (like Javascript). However, interfaces and namespaces -- useful as they are -- are certainly not necessary for an object model. You can do very nice OO programming in C if you are disciplined enough. You don't really need the language to hold your hand.
Don't get me wrong though you PHP and Perl fans, both of those languages are still great at a lot of things and I'm not trying to slam PHP or Perl. I love PHP, it's a very very fun and useful language, I use it a lot, but there are some things it can't do and some things that Perl can't do that Python, Java and other languages can.
Unfortunately, there are issues with using shared memory that would be better off handled by PHP itself. The integer keys need to be unique, which can be a bit of a pain to generate in the first place, but also lead to issues if other software isn't written correctly and simply uses a hardcoded value. Next thing to you, your data is being screwed with by an unknown app.
/tmp/phppersistant or something, and uses file locking to control access. Of course, you'd need to write it all yourself since I don't know of any existing class to perform this. Even then, nothing comes close to a native solution within PHP itself for speed and reliability. If it's so easy using shared memory, why isn't there already a built in solution using this that is part of the default compile? I'd guess that portability of PHP probably makes this solution useless. Last I checked, SysV IPC wasn't available on Wintel boxes. Sure, the functionality is duplicated within different API calls, but it really isn't SysV IPC.
You'd probably be better off using a file based system that stores data in
Don't want to sound demeaning, but I just don't see the practicality of using shared memory for something that should already be included natively. *shrug*
Sorry, I got in the wrong mind track. Too many "BSD is dying" posts screwed up my already messed up brain.
There is no reasonable defense against an idiot with an agenda
:wq