Slashdot Mirror
PHP 5 Beta 1
Sterling Hughes writes "The PHP development community is proud to announce the release of PHP 5 Beta 1. Downloads are available in both source and binary form (for Windows users). A full list of changes is available in the ChangeLog. Some of the new features include much improved OO support, completely revamped XML support, and the default inclusion of SQLite."
The PHP people need to provide ways that people can upgrade the versions of PHP on their system such that they can be reasonably sure that existing users aren't suddenly going to find their sites don't work.
Ah - well man they need to be clearer about it - the phrase makes it sound like they pulled out MySQL support. The Changelog mentions the library - but even it is really brief. I always thought PHP used your local libraries anyway - I didn't realize it came with them in 4.x
Top Most Bizarre/Disturbing Error Messages
what's so difficult about using your own mysql installation?
How do I tell binary PHP to use the installed binary MySQL?
Please read this comment before replying with such an answer along the lines of "compile it yourself".
Will I retire or break 10K?
The sources can be compiled under Windows and most Unices.
But since Windows doesn't come with a compiler, there is a binary provided for Windows.
So what's your point?
The raw speeds of execution between JSP and PHP may be similar (though I suspect that JSP ends up being much faster once the JIT has kicked in and optimized it, after a few executions). Additionally, there are many different JSP runners (Tomcat is only the reference implementation) and the performance between them can be very large (I recommend the JSP runner by Caucho for performance-critical systems. Besides this, PHP and JSP have a very, very large difference between them:
PHP is usually run as a apache mod or sometimes, as a cgi. Because of this, it cannot store session state or cache inside of its process (since the process is either apache httpd, or the cgi, which terminates at the end of a page run). To get around this, any session variables get serialized and stored to disk at the end of each run, then un-serialized at the beginning of the request. This also means you can have no application-level caches of database information, since there is no place to put these. This is fine for small stateful sites or large stateless sites, but for any serious, large web application that has to maintain a lot of state, this ends up being a big performance disadvantage.
JSP, on the other hand, is run from a servlet runner in a persistent process outside of the apache process. At the beginning of the request httpd makes a socket connection (usually a local unix socket, very fast) to the servlet runner and sends the request there. This is slightly more overhead than everything running in-process, but gives you the huge advantage of being able to cache whatever data you wish to inside the servlet runner's process. This means database lookups can be cached, sessions don't need to be stored in disk, timers for maintenance functions can be set, all within the servlet runner's process. This is great for large, complicated web applications but obviously not great for small, stateless systems, since it requires the overhead of a running JVM at all times you want the application to be available.
Two different types of systems, two different purposes. I happen to use both in my professional web development, but use only java servlets and JSP for serious projects.
Not at all. Windows comes on one architecture, so binaries are perfectly acceptable as the default install medium. THere are compatable compilers that you can source if you want. Linux/BSD/Unix needs the default install medium to be sourcecode precisely because of the number of architectures that they run on. Elementary when you think about it, windows simply doesnt need sourcecode by default, yet its available if you really want it.
Because its trivially easy to code for a apache/php/mysql combination on a Windows system, while the production server is running on linux/BSD. Usually it helps to have a quick and dirty test environment available, and thats where apache, php and mysql on windows comes in. Install it and you have a vastly similar environment to the production box, without going outside the development machine. Ofcourse you then test the code on a live-test server to ensure the cross platform hasnt introduced any obscure bugs, but it rarely does.
Cost. Legality.
If there was some way that you could allow the user to have multiple PHP versions all being used as Apache modules where the user could select the one they want using their .htaccess file, that would be a possible solution.
.php4, etc).
To my knowledge this is easily doable, and often done. Although I've never properly looked into it (I keep as far away as possible from virtual hosted environments where this would make sense), I believe the idea would be to compile apache modules for each different version of php you wanted to support, LoadModule each one in in your httpd.conf, then bind each one to a specific file extension (.php3,
I've been using PHP since the 3.0 days and always loved it's speed in development for small dynamic sites. There is truly nothing simpler (IMO) for small sites. Why on earth did PHP ever become so popular as compared to Perl/CGI? It was the simplicity.
Most people accepted the changes from PHP3 to PHP4 without complaining as PHP4 brought simple session support and other needed features. Thousands of developers wrote scripts for small pages and uses, and those scripts got placed on help sites etc all across the web.
The changes above 4.06 where register_globals got turned off by default and -from a simple beginners point of view- to 4.2 where a stunning array of new arrays were added for sessions, post and get variables. Those things broke almost everybodies scripts, and all those thousands of scripts across the web no longer worked as is. Due to this a lot of ISP's no longer upgraded regularly.
At the same time PHP started jumping on the "web application" gravy train, something for which PHP with it's awkward OO support (no automatic calling of parent constructors etc), lack of stateful session support etc was not designed to do. The makers of Zend decided to go the whole hog and redo OO support, add hundreds of seldom used features but ignore problems with backward compatibility and language simplicity.
Congratulations. Now we have a language that is slowly matching JSP in complexity (as all the 1337 "application developers are saying"), is nowhere nearly as well integrated in in true web applications as JSP is (great, it can support Java classes, how many will simply use Java then?) and is leaving the roots of it's enormous success behind.
Take a lesson from Perl's "failure" in web site popularity. Don't keep on adding features for the love of it.
You're new here, aren't you?
It's hard to be religious when certain people are never incinerated by bolts of lightning.
"I know Perl5 accomplished its goals, and then they had an {ap-if-in-ee} to add the RegEx in yet another release of Perl titled Perl6."
Have you even READ anything about Perl6? Any of the apocolypses or exegises? After lots of incremental crud got added in the (very successful) Perl5 series, they are stepping back, rethinking, refactoring, and reimplementing with a very clear and concise goal of optimizing the syntax for the most used cases, as well as fixing known warts. Additionally they are doing this on top of a generic reusable virtual machine, instead of an ad-hoc specific-use interpreter. I don't even like Perl and I realize that Perl 6 is a Good Thing.
It's 10 PM. Do you know if you're un-American?