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."
Top Most Bizarre/Disturbing Error Messages
That's right, now you can say class { @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{q *=2) +=$f=!fork;map{$P=$P[$f^ord[ P.]/&&
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print }
Take a look at the OO changes page. The syntax seems to be converging with Java. I find this amusing in some ways.
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.
--with-mysql=/path/to/mysql
bundled being the key word
vodka, straight up, thank you!
It's still lumped into a great big inconsistent namespace
... pool database connections maybe? no, mysql_pconnect() doesn't count. Oh, and what's with this SQLite thing? had a bit of a fallout with the MySQL team?) ... because that kinda defeats the point of PHP anyway.
..... (x47) really want to like Python, but it's not re-entrant and has a big interpreter which makes its threading capabilities into nothing more than a silly joke (and last I checked, efforts to rectify the situation died back in, what, 1997?), so yeah I admit I use PHP for quite a few web devel jobs. But just because everything else sucks more, doesn't mean PHP doesn't suck any less.
It's still made by a for-profit company who hobble the product in order to not cut into their profit margins too much (Hello? Zend Cache? Optimiser? Compiler? Everything's free in PHP-Land, for a small fee in PHP-Land...)
I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace (as opposed to one URL -- how very un-spider-friendly. Most choke on a ? in a URL and rightly so) and remain persistent (allowing you to do funky stuff like
But come on. Fellas. PHP: Hypertext Preprocessor is the name. Not PHP: Application Server. If those first two issues were fixed it might actually make a seriously powerful hypertext preprocessor. That's something it's reasonably good at. But at the moment it's some sort of bastard preprocessing language run amok that people use to write whole web applications with and other stuff Nature never intended. Perl's got an awful syntax and a total lack of convention (and mod_perl is really byzantine), and I really really really really
I'm not even sure what my point is anymore. But, I think what I was trying to say was this isn't much. Same stuff is true of PHP as has always been true of it... wake me up when they get round to PHP6. An earlier rant I made comparing Perl to PHP (I think I preferred Perl back then) is here. The extended comment history is pretty much the only reason I got a subscription and to be fair I think it's worth the money.
MySQL isn't bundled with it, but you can easily add it yourself when compiling.
Compiling?
Compiling PHP for Windows requires the Microsoft Visual C++ compiler version 6.0 or later.
The Microsoft Visual C++ optimizing compiler version 6.0 or later is available only from Microsoft as part of Microsoft Visual Studio .NET, which costs $1,079 for one non-academic seat. (Microsoft no longer sells a Visual C++ optimizing compiler separately.)
Some people are bound to bring up the $109 Microsoft Visual C++ Learning Edition, but 1. the EULA attached to its library probably does not permit distribution of generated binaries nor public performance (i.e. use on a public web site) of generated binaries, and 2. because it does not have an optimizer, the speed of generated binaries is closer to that of an interpreted program than to that of a compiled program.
If I had any spare time, I'd fix this by porting the build to MinGW.
Will I retire or break 10K?
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?
I'm a PHP programmer and I've begun to recognize a pattern in software: when will we see the end?
Truly, what more can you add to PHP? Why do most software packages continue to add features without actualy providing a subjective goal to strive for?
For example, in the world of Microsoft(R) Windows we see the same operating system have plastered above it "Where do you want to go tomorrow" and above all "n% faster than previous, more stable, etc." When will the goal of a products feature-list finally be met?
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. When will they ever make a product that has a goal? I don't call this competition...I call it beating a dead horse from its grave, like how Intel puts rocket boosters on its crumy brick CPU architecture (Pentium Pro) and adds some more features.
Look at netBSD; it isn't dying, it's still working on its number-one goal: security.
Linux is the same way; it stated from an original design and now is being extended. Am I sounding like I expect a new feature to be a new product? I don't think so... GNU/HURD, of which I know many people are skeptics unto, is builind upon its goals of being a Micro Kernel and add some. What if Linux all-of-a-sudden wanted to become a Micro Kernel? What if Microsoft(R) Windows(TM) all-of-a-sudden wanted to become a Micro Kernel?
The software names, after huge changes to extend their capabilites, are becoming misleading! If you take out a RedHat Linux 5.2 system and compare it with RedHat Linux 8.x, you can't say they are both similar Linux; they are completly different! Sure, it's like comparing apples with oranges on the old and new RedHat, but Kernel-wise the latest Linux Kernel may look completly different and have completly different goals and features than what was hoped for in the verry early Linux kernels. Shouldn't to cause less confusion and more inspiration, they leave the Linux name behind with the old design and all the new stuff that would completly change Linux's software (mechanical?) appearance become known as the new project Herring(TM). I anticipate most of you will reply with "That's why we have VERSION NUMBERS", but hey? You're missing the point.
Microsoft(R)'s Windows(TM) name isn't describing the project's code name, yet the product's retail names are somthing like 95, 98, NT, 2000, XP. Well, it is honest to say that the NT and 2000 products are similar, 95 and 98 products are similar, and the XP product isn't quite similar to 95 and 98 and 2000, but then there was the fiasco that all the 9x users went out to buy product Windows(TM) 2000 and found they had been tricked by Microsoft that 2000 would be like a 95 or 98. Anyone see my point?
As for PHP, and perhaps Perl... Does anyone think they should continue calling those products by their initial names AFTER the programming syntax and methodology becomes completly different or non-compatible than they were first designed?
I'm looking forward to some intelligent answers. Thanks and I'll be a PHP and Perl programmer for a long time to come. d:-)
On Sat, 28 Jun 2003, Marc Richards wrote:
l s&article=%3CPine.LNX.4.56.0306272256280.6461%40th inkpad.lerdorf.com%3E
> I apologies if this is the wrong place for asking. Is non-experimental
> Apache2 support planned for PHP 5?
Nope. Until someone sits down and goes through every 3rd-party library that can be linked into PHP on every platform and identifies whether or not they are threadsafe and under which conditions they remain threadsafe, using PHP in a threaded web server on UNIX is going to remain experimental.
You can of course stick with non-threaded prefork mode, in which case you basically have Apache-1.3.x. Nobody so far have been motivated to test Apache2-prefork+PHP extensively, so even that combination is going to remain experimental.
The basic problem here is that the average UNIX library has not been written with thread safety in mind. You can write very good specific threaded programs on UNIX, but it is extremely difficult to write something which can potentially link in hundreds of random libraries and expect them to all be threadsafe.
-Rasmus
http://news.php.net/article.php?group=php.interna
John Kerry is a Joke!
The will be an interesting battle. JSP and PHP are now broadly identical in syntax and OO implementation. Who'll win? PHP is OS, but JSP has a huge amount of support from corporations.
I'm betting on JSP
((lambda x ((x))) (lambda x ((x))))
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?
um..
O KIE);
extract($_POST);
extract($_GET);
extract($_CO
?
bananas like monkeys.
Something like that already exists...it's called popoon and part of the bitflux cms project.
> No Java, no JSP man. Simply use PHP for web development.
> Forget Java man and go to PHP!
>
> PHP is 4 times faster than Java technology 'JSP' (Java server
> pages).
Substantiate that statement. What benchmark, what workload, etc.
> This tallies because compiled "C" program is 4 times faster than
> Java.
PHP scripts are re-interpreted, at runtime, *for every page hit*.
They're not C.
> Moreover, PHP is getting the object oriented features of Java
> language.
Yeah, *finally*. Partially. This is the 1st go. Java was designed from
the start to be OO, it isn't hobbled on like with PHP.
> The real usefulness of Java is 'Java applets' which run on
> client browsers but on the server side you simply use PHP.
Substantiate.
> PHP is a very lightening fast object oriented scripting
> language. PHP is 100% written in "C" and there is no virtual
> machine as in Java. Nothing can beat "C" language ("C" is a
> language which never dies!!)
Jeez, moron. What do you think the JVM is written in?
> (Java is just another language. The PHP project needs millions
> of Java programmers who can add the Java's language features
> like inner classes, static, private, protected and others to
> PHP. PHP already has some of java' features).
> Java programmers will really "LOVE" PHP as PHP class is
> identical to Java's class keyword.
I use Java and PHP, and I *loathe* PHP. It's single redeeming feature
is that it's everywhere. For the rest, it's a language with crappy
library support, that actively emcourages mixing the presentation and
business layer.
> Read the benchmars of Java JSP and PHP. PHP tops in the speed!!
Substantiate.
Uh, none of those links work, however here is a *recent* comparison of JSP and PHP using several different containers for JSP and PHP. It seems that the server setup has a great deal to do with the speed of the application (duh).
It's interesting that people like to make comparisons to JSP and ASP all the time but don't remark on what platform they run on. Obviously JSP running on tomcat/apache through with mod_jk will be slower than with just plain Resin.
And open should note that a statement like ' Kiss and say goodbye to Java language!!' almost sounds like a troll, when you consider Java is used for a great deal more than web applications, indeed the servlet functionality that JSP relies on is a *very* small portion of the overall tools that Java supplies to developers.
But whatever, use the right tool for the job and try to remember it's technology, not religion. The more options the better IMO.....
1400x1250 in a 640x480 world...
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.
Considering that I've been a Linux/Apache/MySQL/PHP developer since they each were available, it's just disgusting that they're making it harder to support MySQL at a time when LAMP is a recognized contender against Microsoft. I am not going to fscking rebuild a bunch of sites' dbs and recode MySQL-specific PHP code just because the GPL gives these guys a rash. Certainly when PHP was under Rasmus's authorship and control, he was never this sort of jerk.
I'm not saying I can't take the trouble to link in MySQL libraries, just that there's no good excuse for the PHP folks to make me - and thousands of others - go to this trouble. They could, if nothing else, distribute their nonGPL PHP, plus a GPL kit that adds MySQL support, if they're too scared that the GPL will give them cooties.
"with their freedom lost all virtue lose" - Milton
Yes yes.. To sooth all the scalp scratching surrounding PHP and FREE (quality) cacheing and encoding look no futher than
.001 slower than zend (faster than PHP Accelerator) and it FREE! Did I mention it works with Zend Optimizer , Zend Encoder and it can also Encode (protect) PHP files?
MMcache - http://www.turcksoft.com/en/e_mmc.htm
It's only a split second
I'm too damn good to you people! ; )
PS: PHP makes programming fun again. Thats why people like to use it. Simple really.
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,
PHP 5 isn't really documented in the PHP 5 manual yet as there are still a few features on the move, and new features to come, but here's a list of PHP 5 related articles and presentations:
Faq: Where can I get more information about PHP5?
Enjoy!
Hey HeadDown. You're right to take the guy to task, s/he made some crazy comments. But I can at least partially substantiate speed issues. Back in 2000, I worked with Sabeer Bhatia (the Hotmail guy) on a startup called Arzoo. Our product (a Web site similar to epinions) was almost 100% Java, except for a bit of Perl for screen-scraping and searches. But anyway, it was slow -- first with Tomcat, then with JRun. At one point, we gave a private preview to 1,000 journalists. They didn't even visit the site all at once, they trickled in over the course of 3 days or so. Just that was enough to hammer the site. We ended up running cron jobs that would reboot the farm, round-robin, just to solve memory issues and instability.
Now, you can say, well, that was 2000! Try it now! OK. At SST, we have a team that is using Tomcat now. Although the instability is gone, the speed is still an issue -- they have wait screens as you click through the app. My team is working with PHP, and has no wait screens, and no need for them (with 1 exception). Our pages are actually more computationally stressful than the Java stuff, yet PHP is delivering the result to the browser faster.
As a final point, you might suggest that the teams I've worked with do not understand Java or how to run it well. It's no skin off my back if you make that argument -- it's not me doing this stuff, so no blow to my ego. But I think working with 2 different teams over the course of 3 years says something. Perhaps, at the very least, if Java really can handle a bigger load, it is so difficult to tune that mere mortals would do better with PHP.
My Greasemonkey scripts for Digg &
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.
Instead of ODBC, you'd be better off using the pear/db module as middleware. It supports more databases (mysql, odbc, sqlite, pgsql, etc.) and if it isn't the future standard for database access in PHP, something like it will be.
I've been using PHP's built-in (until now) MySQL functions, because they're faster than pear/db, but this licensing dust-up has convinced me that portability among database vendors is worth a performance hit. And the pear/db module is getting increasing attention and is likely to get faster.