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

83 of 398 comments (clear)

  1. They pulled MySQL out! by baptiste · · Score: 5, Interesting
    Check this:
    Due to issues surrounding the MySQL 4.0 license, the MySQL are no longer bundled with PHP. For more information on these licensing changes, please refer to the MySQL Licensing Policy.
    Wow - that's not a smart move. I guess this is a GPL (MySQL) vs Apache (PHP) license issue? Anyone have more details?
    1. Re:They pulled MySQL out! by CausticWindow · · Score: 5, Informative

      Check this thread on Google groups.

      --
      How small a thought it takes to fill a whole life
    2. Re:They pulled MySQL out! by Triumph+The+Insult+C · · Score: 3, Informative

      what's so difficult about using your own mysql installation? this refers to the bundled libraries. aside from changes mysql has made to 4.1, this is a non-issue.

      maybe this will get them to included a bundled version of postgres

      --
      vodka, straight up, thank you!
    3. Re:They pulled MySQL out! by baptiste · · Score: 4, Insightful

      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

    4. Re:They pulled MySQL out! by Ark42 · · Score: 2, Interesting


      The thread mentions somebody at mysql is working on a exception to their license to all PHP to continue to bundle the mysql library extension or whatever. I would hope it gets resolved by the final PHP5 and even if not, most distros like Redhat will probably have the RPMs set so this isnt an issue anyways.

    5. Re:They pulled MySQL out! by Matty_ · · Score: 2, Informative

      I am pretty sure that PHP 4 comes with a MySQL client library, and it is enabled by default during 'configure'.

      In FreeBSD Ports, it compiled the MySQL client package and uses it instead.

  2. Improved OO! by Anonymous Coward · · Score: 4, Funny

    That's right, now you can say class { @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
    @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q *=2) +=$f=!fork;map{$P=$P[$f^ord
    ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
    close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print }

  3. Turning into Java? by alannon · · Score: 5, Interesting

    Take a look at the OO changes page. The syntax seems to be converging with Java. I find this amusing in some ways.

    1. Re:Turning into Java? by hhnerkopfabbeisser · · Score: 2, Interesting

      No offence meant, but even if PHP's OO-support will be perfected at some point in the future, it would rather be a Smalltalk-clone (or python or ruby or whatever) than a Java-clone, which makes a hell of a difference.

    2. Re:Turning into Java? by justMichael · · Score: 2, Interesting

      Personally I'm glad to see it. I'm tired of having to create a new object just to call one of it's methods (see Dereferencing). Not to mention not being able to throw/catch Exceptions.

    3. Re:Turning into Java? by pnatural · · Score: 2, Insightful
      Python has abstract classes:
      class Foo:
      pass

      class Bar(Foo):
      pass

      assert isinstance(Bar(), Foo)
      Interfaces aren't an issue, either. Sun(tm) Java(R) has the notion of interface to get around a language flaw -- lack of multiple inheritance. Python has MI and thus doesn't need interfaces.
  4. Problems with newer versions by Sanity · · Score: 4, Insightful
    I recently developed a number of sites in PHP and ran into serious problems when it became clear that most hosting providers use older versions of PHP, and are scared to death to upgrade lest they screw things up for their existing users.

    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.

    1. Re:Problems with newer versions by CausticWindow · · Score: 2, Insightful

      There's no problem running different versions of php on the same webserver. We're running php 3 and php 4 here, without any problems.

      --
      How small a thought it takes to fill a whole life
    2. Re:Problems with newer versions by larry+bagina · · Score: 5, Informative
      I agree. Even though there are huge differences between version 3 and version 4 (and now version 5), there are also lots of differences between minor versions -- stuff like new functions, changes to how functions work (beyond just bug fixes), etc. Nevermind that there are hundreds of optional libraries and setup parameters, making every installation unique.

      If you're doing a non-trivial php site, and trying to make it work with different versions of php (osCommerce, for example), you end up having to rewrite many functions yourself to make sure they work consistently.

      I like PHP, but it suffers from an "incrementalism" design approach. Some stuff really needs to be rethought, and I think PHP 5 is on the right track to doing that.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    3. Re:Problems with newer versions by Sanity · · Score: 4, Insightful
      If you're doing a non-trivial php site, and trying to make it work with different versions of php (osCommerce, for example), you end up having to rewrite many functions yourself to make sure they work consistently.
      Absolutely, this is exactly the experience I had.
      I like PHP, but it suffers from an "incrementalism" design approach. Some stuff really needs to be rethought, and I think PHP 5 is on the right track to doing that.
      I hope you are right, but right now I am more concerned about how to deal with differences between different PHP4 versions - it is immensely frustrating to inadvertantly use a function only to discover that it doesn't exist on your new ISPs version of PHP (and of-course they won't upgrade for love nor money lest they upset their other users).

      Someone involved in PHP needs to take a cold hard look at this issue and figure out how to tackle it head-on, or they will find that with each new version, people take longer and longer to take advantage of new features which will cause PHP to stagnate.

      With Java, at least I know for a fact that some Java 1.1 code will work with Java 1.4 and as a result most ISPs keep their Java versions quite up-to-date.

      Until the PHP team treat lack of backward compatability as a bug, this problem will persist.

    4. Re:Problems with newer versions by Motherfucking+Shit · · Score: 4, Interesting
      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.
      The only major compatibility issue that I can think of between, say, the 4.1 branch and the 4.3 branch is that register_globals defaults to 'Off' in newer versions. If you leave it that way after installing, then yes, a lot of older scripts will break. Most of the shared/virtual hosting providers I've had to do script installs on, which have actually upgraded their PHP versions, just installed 4.2x or 4.3x and then manually turned register_globals back to 'On' in the php.ini file.

      To the best of my recollection, there isn't much else that's not backwards-compatible. Even where functions have been renamed (e.g. socket_get_status), the old function names still work, and while deprecated, they don't seem to be going anywhere soon. I have no trouble digging up stuff I wrote back in '99 or 2000 and getting it to work under PHP 4.3; though I do have to enable register_globals in those cases.

      Only problem I ever ran into with PHP where stuff quit working after an upgrade was on a test Apache2 server. It turned out to be a bug related to posted form data. I wouldn't use Apache2/PHP on a production server yet anyway, though; and 1.3.27 still gets the job done. I haven't had time to play with PHP5 yet, so I'm not sure what the differences are in that version.

      I agree at the surprising number of hosts who simply haven't updated, though. There are a lot of hosts still running 4.1x, and even (yikes) 4.06, who just won't upgrade for whatever reason. I do most of my coding these days on 4.2 or 4.3, and have run into plenty of belligerent hosts who refuse to upgrade from a two-year-old release. Typically I just have my clients move to a better host; the providers who don't stay reasonably with the times will eventually figure out that it's hurting their bottom line.
      --
      "BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
    5. Re:Problems with newer versions by Billly+Gates · · Score: 2, Informative
      One of the reasons to use PHP or ASP over CGI is speed.

      Both PHP and ASP are compiled and linked directly to the webserver daemon. CGI uses an interface and the engine is not loaded directly with the web server. This makes it alot slower and you lose all the benefits of what php has to offer.

    6. Re:Problems with newer versions by steveg · · Score: 2, Insightful

      If you are trying to match the options from a previous install, what I do is create a page with phpinfo() on it. This displays the entire configuration, including the compile configuration. I just cut and paste that section of the output page onto the command line and I get a build of the new version with the same options.

      Doesn't help if they've changed how an option is invoked at ./configure time, but other than that it does the job.

      Runtime behavior changes are a different matter.

      --
      Ignorance killed the cat. Curiosity was framed.
  5. Re:mysql? by Triumph+The+Insult+C · · Score: 5, Informative

    --with-mysql=/path/to/mysql

    bundled being the key word

    --
    vodka, straight up, thank you!
  6. OO support by Anonymous Coward · · Score: 2, Funny

    I just want to know when they're going to add OO support to as.

  7. Re:Don't mod me down... by Anonymous Coward · · Score: 2, Interesting

    Does PHP5 cache compiled scripts yet? That's where ASP gets it's speed from.

  8. Yeah Yeah... by Second_Derivative · · Score: 3, Interesting

    It's still lumped into a great big inconsistent namespace

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

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

    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.

    1. Re:Yeah Yeah... by eadz · · Score: 3, Informative

      I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace
      You can! Use a PHP file instead of a directory for your DocumentRoot in apache.
      I.e DocumentRoot /var/www/servlet.php
      Now all requests are handled by servlet.php.

    2. Re:Yeah Yeah... by rasjani · · Score: 2, Interesting
      That articly sucked big time. All those are really really really dirty hacks and shows that the writer didnt know apache too well.

      I urge that man to rtfm a bit more before posting nonsense like that. Without even testing i can tell him that mod_rewrite is 100% more elegant way to archive what he was after than any of his 3 choises combined.

      Think about these rules for example (Not verified to work but im sure someone who knows apache syntax knows what i mean)

      • rewriteengine on
        rewriterule ^/article/(.+)$ /processor.php?article_id=$1 [P,L]
        rewriterule ^/article/(.+)/page/(.*)$ /processor.php?article_id=$1&page=$2 [P,L]

      And so forth .. What you need to do in your code is to print out links that will fit the rules you have set up with mod_rewrite ..

      --
      yush
    3. Re:Yeah Yeah... by eadz · · Score: 2, Informative
      Yep. It has one drawback though, and that is all requests are handled by servlet.php. If you have an images/ directory, you'll have to put code in your servelet.php to include those files!
      A more flexable approach I use for the same effect is a .htaccess :

      RewriteEngine on
      # if requested resource doesn't exist
      RewriteCond /%{REQUEST_FILENAME} !-f
      # redirect to default request handler
      RewriteRule ^(.+) /logic.php

      This means if you request /page.html and page.html exists it serves it. If it doesn't exist the request is handled by /logic.php. You can then either serve up some content based on the url or return a 404 header.
    4. Re:Yeah Yeah... by Second_Derivative · · Score: 4, Informative

      Nah, I reckon one could handle it like this...

      <VirtualHost *>
      ServerName www.myhost.com
      DocumentRoot /home/myhost/engine.php
      Alias /res /home/myhost/resources
      </VirtualHost> ... or something. I tried it on my server and it seems to work a treat. Once again cheers for the tip

    5. Re:Yeah Yeah... by pacman+on+prozac · · Score: 4, Informative

      My biggest complaint about PHP is the joke that they pass as "error handling". Yeah great, thanks for exposing all my path names to the outside world if something goes wrong.

      Psychic abilities will be added to PHP as of version 6.6.6. From here on you will be able to simply think of the configuration you want and it will be set in php.ini. No longer will you have to read the extremely comprehensive online docs including the manual and especially not the ENTIRE SECTION dedicated to error reporting and logging that tells you extremely clearly how to do what you have just complained is impossible. You would not need to read that page and find the two links within the 1st side that show very clearly information on the display errors, error_log for custom logs and of course log errors to put the errors in the apache logfile.

      Your biggest complaint is that you are too lazy to read the manual and you expect everything to be done for you. No programming language can help you with this.

  9. The obligatory predictions... by UsonianAutomatic · · Score: 5, Funny
    1. PHP Sucks, Perl is a much better language.
    2. PERL sucks, PHP does most of the same stuff Perl does but you can still read your own code a week later
    3. PHP isn't a real language, it's just a bunch of wrappers thrown around stuff. PHP sucks.
    4. Who cares about MySQL support, MySQL's not a real database anyway. MySQL sucks. PostgreSQL rulez.
    5. WTF I upgraded to PHP 4.1.2 and all my form submit scripts stopped working. Whats this register_globals crap anyway what a pain.
    6. Continue with language specific criticisms; loose typing, OO not as strong as Java, et cetera.
    1. Re:The obligatory predictions... by glwtta · · Score: 4, Funny
      You forgot the obligatory followup to number 2:

      WTF is "PERL" anyway? PHP sucks, Perl rules.

      --
      sic transit gloria mundi
    2. Re:The obligatory predictions... by Tablizer · · Score: 3, Funny

      You forgot one:

      7. OOP sucks, there is no proof it is better, it is only a personal choice that maps to some people's head better but not all and the reuse claim is so 80's because up-to-date OO'ers don't claim that anymore.

      If you are gonna put a troll out of business, do it right ;-)

    3. Re:The obligatory predictions... by Shinobi · · Score: 2, Funny

      "PERL sucks, PHP does most of the same stuff Perl does but you can still read your own code a week later"

      How about "PHP doesn't require you to be drunk to be able to read and debug the code you wrote earlier the same day"?

      Been there, done that....

    4. Re:The obligatory predictions... by Xpilot · · Score: 3, Funny

      6. Continue with language specific criticisms; loose typing, OO not as strong as Java, et cetera.

      The word "loose" was used correctly in a Slashdot comment! Quick, take a picture!

      --
      "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
    5. Re:The obligatory predictions... by ceeam · · Score: 2, Insightful

      Practical Extraction and Reporting Language -> PERL. Huh? Not?

  10. Still re-coding for register_global_variables... by vandan · · Score: 2, Interesting

    God damn!
    I'm half-way through re-writing our website to remove our dependance on the depreciated register_global_variables stuff which I learned to live with and then was told was a stupid idea.
    I'm hoping they don't break too many other things 'cause being a php beginner, the whole process is a bit of a nightmare.

  11. Destructors! Hooray! by Wuhao · · Score: 2, Insightful

    I have always been very annoyed not having destructors in PHP. PHP5 includes destructors, along with public/private class members. I can't wait for this to be released as a stable version.

  12. Requires Microsoft Visual C++ by yerricde · · Score: 5, Interesting

    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?
    1. Re:Requires Microsoft Visual C++ by Anonymous Coward · · Score: 3, Informative

      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.


      Exactly version 6.0, not "later" (because you can't compile/link with GPL stuff with the 7.0/.NET compiler due to licensing restrictions).

    2. Re:Requires Microsoft Visual C++ by Mostly+a+lurker · · Score: 2, Interesting
      Actually, you can download the non-optimizing compiler for free from their web site.

      I stand to be corrected, but I believe this is no longer true. On the other hand, it may be possible to work with the Intel C++ compiler. It seems to play with MS Visual C++ stuff quite well in most cases.

  13. But how? by yerricde · · Score: 3, Insightful

    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?
  14. Final version by InsaneCreator · · Score: 2, Informative

    So how long until we get the final version?

    I'm currently developing a PHP project with lots of OO code and it's about as plesant as removing your eyes with a rusty spoon (some control structures implicitly copy objects, they don't know how to return references, you can't write $a->getB()->doSth(); ...).

    Improved OO support in PHP5 would be really nice riht now.

  15. Yawn by Anonymous Coward · · Score: 3, Interesting

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

    1. Re:Yawn by c13v3rm0nk3y · · Score: 2, Insightful

      ...I've begun to recognize a pattern in software: when will we see the end?

      Well, never.

      Software design is unlike most every other discipline in the world. Your job is never finished until the product is dead. There are always bugs to fix, inconsistencies to remedy. Even the action of fixing bugs will create or uncover new ones. The fact is, if you release version 1.0, by definition you will also have to release version x.y for the entire life-cycle of the product. This also implies that versions may not be infinitely forwards- or backwards-compatible. At some point you have to abandon old releases.

      Look at netBSD; it isn't dying, it's still working on its number-one goal: security.

      According to the netBSD Goals page, security is not paramount. Certainly it take back seat to correctness of code, performance and wide platform support. Perhaps you mean OpenBSD? Either way, if you are going to make security your number one goal, you are compelled to updating and maintaining your code base! Security is a job that is never finished.

      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?

      Well, one of the early criticisms of Linux was that it wasn't a microkernel design. Some MINIX folks really thought Linus was taking a step backwards, though his intention was just to run a real UNIX on his intel box.

      The NT kernel can be considered a microkernel. Very few "pure" microkernel implementations exist, and even fewer exist in the wild. By most definitions the Windows NT kernel is a microkernel.

      Anyway, it's a moot point. Yes, redesigning the Linux kernel to be a microkernel would be significant, but this is why they have odd-number releases to shake the biggest bugs out. Architecture changes like this are part of any long-running project. Do I think they should do it? No. Do I think it would be more are less Linux? Again, no. If the only thing we could call linux is 2.4.x then the project is dead for sure.

      How Microsoft or the PHP people label their respective products is really not that important. I'm not sure this is any kind of trick. Oh sure, Microsoft wants to make sure that people stay current, so it markets the latest release as The Best Ever, You'll See, but everyone does that. It helps their bottom-end in all sorts of ways, not just in immediate units sold.

      Supporting old releases is expensive and painful. Few companies can afford to do so. How old releases are grandfathered is important, but we have to realize that old software must die. Personally, I'm glad Microsoft continued making improvements to Windows over the years (aren't you?). I just don't give a shit what they call it, as it is obviously cut from the same cloth when I fire up my desktop at work.

      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 certainly do not agree.

      The fact is that PHP 3, PHP 4 and PHP 5 all do the same sorts of jobs. The language will continue to run blogs and forums, process forms and maintain accounts for porn sites. That will not change. Eventually, as 5 matures it will replace 4 as the dominant release in current use. PHP is right for bumping the major version number when major architectural changed have been made. Whether or not syntax changes all that much (and from my review of the top article, the syntax of the language is not about to change radically) is relatively unimportant. As long as the provider (PHP) gives the implementer (the PHP developer) a heads-up on those changes, and sufficient time to revie

      --
      -- clvrmnky
    2. Re:Yawn by damiam · · Score: 3, Insightful
      I'm looking forward to some intelligent answers.

      You're new here, aren't you?

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    3. Re:Yawn by Hard_Code · · Score: 3, Insightful

      "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?
  16. Re:Don't mod me down... by loginx · · Score: 2, Informative

    Not natively (yet) but there are several tools that do this for PHP, such as the Zend Optimizer or the popular PHP Accelerator (PHPA) http://www.php-accelerator.co.uk/

  17. Kinda kludgey by Sanity · · Score: 2, Informative
    There are good reasons that ISPs want to use mod_php - and using your proposed solution these benefits are lost.

    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.

    Of course, the real solution is for the PHP development team to take the issue of backward-compatability more seriously then they clearly do at the moment.

    1. Re:Kinda kludgey by elbobo · · Score: 3, Insightful

      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.

      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, .php4, etc).

  18. Here's the word by john_smith_45678 · · Score: 3, Informative

    On Sat, 28 Jun 2003, Marc Richards wrote:
    > 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.internal s&article=%3CPine.LNX.4.56.0306272256280.6461%40th inkpad.lerdorf.com%3E

  19. JSP by nepheles · · Score: 3, Interesting

    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))))
  20. Re:Windows Users by hhnerkopfabbeisser · · Score: 4, Insightful

    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?

  21. Re:Still re-coding for register_global_variables.. by FryGuy1013 · · Score: 5, Informative

    um..

    extract($_POST);
    extract($_GET);
    extract($_COO KIE);

    ?

    --
    bananas like monkeys.
  22. Advice & Observation by calebb · · Score: 2, Informative

    Advice:
    The default method of configuring PHP is with the CGI SAPI module (i.e., php.exe); A much better choice (imo) is to configure the CLI SAPI module - all you have to do is build the CLI SAPI .dll (Depending on which webserver you're using - php4apache.dll for Apache, php4isapi.dll for IIS)

    (Also, many websites refer to the two config methods as CGI and SAPI; This is not really correct since CGI *is* a server API. What they really mean is CGI SAPI & CLI SAPI)

    So, why go through the trouble to compile .dll's to run PHP as an integrated CLI SAPI? Performance! This method was officially documented as a stable feature in the December 2002 build of PHP.

    Ok, so you're still asking WHO CARES??? Here's why you care: When you use the '.dll' method (CLI SAPI), much more of the processing work is passed onto the kernel resulting in fewer system calls. A LOT of people complain that PHP is slow & inefficient compared to other webservers, but oftentimes, these people haven't tried the CLI SAPI of PHP! Their point of reference is an ISAPI webserver (IIS) & they are comparing apples to oranges.

    To find out what SAPI you're using, just execute php -v

    Observation:
    PHP adds new functions & deprecates other functions waaaay too often; No wonder people are leery of upgrading!

    1. Re:Advice & Observation by aint · · Score: 2, Informative

      This post has some problems as there is no such thing as a CLI dll... In Windows you have two php.exe binaries, the cli in the cli/ folder, and the cgi in the root php source folder. The CLI WILL NOT work with the web server, it's a Command Line Interface.

      Regarding the DLL, you are referring to SAPI modules, not CLI. And yes, using them is preferred (although depends on who you ask :) but this topic is not related to this thread on the PHP 5 Beta.

  23. XML transformation pipeline by graveyhead · · Score: 2, Interesting

    I have always wanted PHP to have an XSLT based transformation pipeline, similar to what Apache Cocoon has. I would like to be able to write source documents in XML, arbitrarily transform XML into HTML and PHP, interpret the PHP, possibly transform again and finally output the results. I know I could build this top-down from within a single PHP document, but I'd like this pipeline to be a part of the mod_php distribution, with the .XML file extension mapped to the pipeline processor.

    Anyone wanna help me build it?

    --
    std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
    1. Re:XML transformation pipeline by jojo80 · · Score: 3, Informative

      Something like that already exists...it's called popoon and part of the bitflux cms project.

    2. Re:XML transformation pipeline by Dalroth · · Score: 2, Informative

      http://www.interakt.ro/products/Krysalis/

      You can also use PHP as a generator in Cocon.

  24. Re:Kiss and say goodbye to Java language!! by HeadDown · · Score: 3, Informative

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

  25. Re: Just use ODBC by Billly+Gates · · Score: 2, Insightful
    For those using a Unix or Unixlike system there is also UnixODBC.

    Problem solved.

    Its better software engineering wise to use layer with ODBC or something similiar to access your database. Changes to your database will not require whole rewrites. Also you can host the database on a different server other then your web one.

    I consider myself an amuture database programmer so feel free to correct me if I am wrong regarding something like ODBC to connect to a remote server. I think Oracle has some proprietary redirector/protocal similiar to ODBC but I have never used it and can not comment.

    Anyway its not a problem and its good on your resume to learn general sql commands and switch between Sybase, postgreSQL, and MYsql rather then hardcode to a specific database.

    I also recommend Interbase if your looking for a great way to learn ANSI sql via odbc. Its free from Borland. PostgreSQL looks cool but it has mediocre WIndows support via cygwin.

  26. Re:Kiss and say goodbye to Java language!! by crunchywelch · · Score: 4, Informative

    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...
  27. Re:Kiss and say goodbye to Java language!! by alannon · · Score: 5, Insightful
    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!!)
    How did this barely-literate rant get modded up to +2? What difference does it make that PHP is written in C? Java is written in C, and the JIT has some hand-coded assembler in it as well. So what? The HOWTO that is linked to hasn't been updated in 2 years and the benchmarks linked in the HOWTO are no longer even on the web.

    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.
  28. Breaking MySQL support - what *sses by wytcld · · Score: 3, Interesting

    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
    1. Re:Breaking MySQL support - what *sses by doe · · Score: 3, Interesting

      Its would mean breaking MySQL's GPL license if PHP bundled current version of MySQL client libraries.

      This because FSF claims that Apache and PHP licenses are not GPL compatible, thus linking against those is not premitted. It does not help that MySQL AB has chosen to change their client library license from LGPL to GPL after release 4.0 of MySQL

      Nothing to do with the PHP development team really.

  29. Re:Windows Users by Tony-A · · Score: 2, Funny

    So what's your point?
    "But since Windows doesn't come with a compiler,"

    Looks kinda crippled there, wouldn't you say?

  30. FREE!! -- PHP Encoder and Cacheing -- FREE!!! by Anonymous Coward · · Score: 5, Informative

    Yes yes.. To sooth all the scalp scratching surrounding PHP and FREE (quality) cacheing and encoding look no futher than

    MMcache - http://www.turcksoft.com/en/e_mmc.htm

    It's only a split second .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?

    I'm too damn good to you people! ; )


    PS: PHP makes programming fun again. Thats why people like to use it. Simple really.

  31. Re:Does it really matter? by larry+bagina · · Score: 2

    I use PHP + IIS + MySQL + Dreamweaver to test/debug on my local machine.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  32. Re:Windows Users by Richard_at_work · · Score: 3, Insightful

    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.

  33. Re:Does it really matter? by Richard_at_work · · Score: 3, Insightful

    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.

  34. Re:Does it really matter? by ymgve · · Score: 3, Insightful

    Cost. Legality.

  35. Re:What about apache2? by Billly+Gates · · Score: 2, Informative
    Well I tried out FoxServ on my Windows2k box because I am lazy and did not want to configure php and apache2 myself.

    You can find it on sourceforge.

    Its basically apache2, perl 5.6, tlc/tk, python 2.2, mysql, and php 4.2 installed as one package. I think their is a Unix version as well but I do not use it.

  36. Pining for the Fjords! by fm6 · · Score: 2, Funny

    I don't know whether to flame you or thank you for leaving "hl=no" in that URL. I guess I should thank you, since figuring out why Google was assuming I was Norwegian was very instructive!

  37. PHP 5 Documentation update by aint · · Score: 4, Informative

    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!

  38. Re:Windows Users by pompousjerk · · Score: 2, Informative

    Yeah, and I got PHP5b1 up and running in about 10 minutes. No time spent compiling. ;)

    Nothing works! At least, nothing using PHP4's OO features. And I used a lot of PHP4's OO features!

    I'm going to spend the rest of the day tearing out my hair. Especially because I'll have to rewrite 1000+ lines of PHP code....

  39. Re:Kiss and say goodbye to Java language!! by Anthony+Boyd · · Score: 4, Interesting
    PHP is 4 times faster than Java technology 'JSP' (Java server pages).
    Substantiate that statement.

    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.

  40. Both by Delirium+Tremens · · Score: 2, Informative

    Both will win.
    The latest news from Sun is that J2EE 1.5 will support scripting languages. And the reference implementation will be done in PHP.
    If you don't believe, check some of the news site reporting on JavaOne 2003.

  41. PHP fragmentation, lack of cohesion by theolein · · Score: 4, Insightful

    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.

    1. Re:PHP fragmentation, lack of cohesion by aint · · Score: 2, Insightful

      BOGUS.

      First of all, the superglobals you speak of were introduced in PHP 4.1.0 not 4.2.0, and register_globals was turned off by DEFAULT (default being the keyword there) as of PHP 4.2.0, not 4.0.6. And this is not the reason why ISP's don't upgrade as configurations can be changed. This is why announcements announce these changes, why ./configure mentions it, and why it's so heavily documented. This is also why PHP has a file named php.ini

      Regarding complexity, the new PHP 5 features are OPTIONAL, you do NOT have to use OOP at all. It's your choice. You, the user, are given choices, so it's up to you to use whatever you want. The backwards compatibility remark is funny as a typical member of the PHP-DEV team is very aware of BC and tries abnormally hard to keep it. There is even a PHP 5 directive named zend2.implicit_clone to help out with these ZE2 changes.

      Basically, this post is silly and the "insightful" rating is bogus. Your typical naysayer hard at work.

    2. Re:PHP fragmentation, lack of cohesion by OzRoy · · Score: 2, Informative

      Actually if you go read that OOP page properly you will see that they added a lot of features needed to be a proper OO language. In every case they said "If you don't use this feature, the old method will be used". As far as I can tell this keeps compatability.

      As for the new arrays that appeared in newer versions of PHP that broke everyone's scripts. It's a simple configuration change that will revert PHP back to the old methods while you change your scripts to get them working again.

      Those new arrays ARE necessary. The old method of getting your form data is badly insecure. They explained all this, and gave example code as to why the old ways were bad. I believe it went something like this:

      if (isAuthenticated()) {
      $authenticated = true;
      }

      In that example $authenticated would Never be set using a form. But, if register_globals is set to on, all a person would have to do is pass a 'authenticated' parrameter to the script and they have instant access. Yes it's a pretty stupid thing for a programmer to do, but these things do happen. I think everyone should be FORCED to upgrade to the new version.

      PHP is Still simple. You can still write the basic code you want to write, but it now gives us the functionality we want to make really powerful scripts. At least I know I want them. I will use 90% of those new features as well. As far as I'm concerned these changes are LONG overdue and it's about time PHP caught up with the real world.

  42. Re:Exactly by Delphiki · · Score: 2, Interesting

    That's kind of funny, considering the Linux users I know can all get things done. The Windows users I know quite often have to ask the Linux users how to get things done.

    --

    Feel free to mod me "-1 - Angry Jerk".

  43. PHP, the new "Camel" by eLoco · · Score: 2, Funny

    If PHP had an official mascot the way that Perl has the camel, I'd recommend they swap since PHP looks more like a "horse designed by committee" every day.

    --
    sig != null
  44. Re:Still re-coding for register_global_variables.. by amanpatelhotmail.com · · Score: 2, Informative

    even better: (add to .htaccess file to your codebase directory) php_flag register_globals On

  45. More info on MySQL/PHP5 by mtabini · · Score: 2, Informative

    In case anyone is interested, I've followed the PHP5/MySQL on my blog. (it also contains instructions for getting MySQL back into PHP)

  46. Re:No Function overloading? by Malcontent · · Score: 2, Informative

    It's not bad. In the case of PHP it's not needed. PHP is not a storngly typed language so you can write a getBalance() function which can take any damned thing you can pass in.

    Once inside the function you can test the passed in variable and take appropriate action.

    You can also do other crazy things like declare functions without parameters and pass parameters into them.
    You can declare methods that act as "default" method handlers.
    You can add methods to objects at runtime!.
    Hell you can even define classes at runtime.

    It's highly dynamic.

    If

    --

    War is necrophilia.

  47. Re: Just use PEAR/DB by PizzaFace · · Score: 4, Informative

    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.