Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 5 RC 1 released 388

Posted by CmdrTaco from the get-your-develop-on dept.
An anonymous reader writes "PHP just released the first release candidate of PHP 5 after 4 beta releases. It is considered stable and feature-complete -- so get testing!"
This discussion has been archived. No new comments can be posted.

PHP 5 RC 1 released More

PHP 5 RC 1 released

Comments Filter:

  • Power Power Power (Score:2, Interesting)

    by ObviousGuy ( 578567 )
    It's funny, I remember when it was a main tenet of programming that data should be separate from presentation. However, PHP has shown just how powerful integrating data and presentation can be through inlining code directly into a webpage layout.

    As Perl seems to fade more into irrelevence, languages that hold onto a strong central theme like PHP, Python, Ruby, and Dylan are coming to the fore to take its place. Whenever I see a story about PHP, I think more about the death throes of Perl than about PHP i

    • Re:Power Power Power (Score:5, Insightful)

      by Anonymous Coward on Thursday March 18, 2004 @05:27PM (#8604005)
      It's funny, I remember when it was a main tenet of programming that data should be separate from presentation. However, PHP has shown just how powerful integrating data and presentation can be through inlining code directly into a webpage layout.

      Try something complicated. You'll change your tune right quick.
      • I've tried both simple and complicated. It's in the design. You can easily write incomprehensible code that's not easy to maintain in any language.

        • Re:Power Power Power (Score:5, Informative)

          by Anonymous Crowhead ( 577505 ) on Thursday March 18, 2004 @05:46PM (#8604188)
          It's in the design.

          Yep. And if you inline presentation and data in a complicated web app, that's bad design.

          • The "good design" police... have fun with it! (Score:4, Interesting)

            by turnstyle ( 588788 ) on Thursday March 18, 2004 @06:04PM (#8604329) Homepage
            For starters, I'd say that PHP is more a challenge to ASP than Perl.

            (I see plenty of Windows users adding PHP to systems that already support ASP)

            In any case, all the talk of "good" design ignores all the new and not hardcore coders who can play with something like PHP (as well as ASP) but not so much Perl.

            (note aslo that Apple includes PHP on their OSX boxes)

            My point is that, in my opinion, one of the things so nice with PHP is that it's just fun to play with. If some coders want to "inline" their code, let them, and let them have some fun, eh.

            It's like the pre-Web days when "designers" got into scripting with HyperCard and Lingo.

            Everybody's welcome.

    • Re:Power Power Power (Score:4, Insightful)

      by Anonymous Coward on Thursday March 18, 2004 @05:28PM (#8604012)
      Powerful is one thing, maintainable another.

      Keeping data and presentation separate is still the best thing to do. But that's why we have CSS. So unless you're still using tables, font tags or whatnot, you're not integrating data and presentation.
    • this is one of the things that I hate about php.. inline into a web page is HORRIBLE, it's hard to read, it's easy to miss a badly spelt variable name..

      When I am forced to use php, I am relying on templating tools all the time (no different then when I am using perl or any other language in the end..)

      • Re:Power Power Power (Score:2, Insightful)

        by w3weasel ( 656289 )
        inline into a web page is HORRIBLE, it's hard to read, it's easy to miss a badly spelt variable name

        PHP can be written as OO or Speghetti; inline with presentation or seperate... the choice is yours...
        (if you know what you are doing... PHP can be incredibly flexible)

      • Re:Power Power Power (Score:5, Informative)

        by loginx ( 586174 ) <xavier@NosPam.wuug.org> on Thursday March 18, 2004 @06:02PM (#8604313) Homepage
        Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

        There [php.net] are [php.net] several [php.net] templating [php.net]
        engines [php.net] available [php.net] that effectively separate the application
        layer and the presentation layer for PHP applications.
        These engines are quite heavily used also (check the source code of most large
        open source projects and commercial applications...)
        • Wish I had mode points for you. Those are great links!.

          Now which one[s] do you recommend, and why?

          • Re:Power Power Power (Score:5, Interesting)

            by loginx ( 586174 ) <xavier@NosPam.wuug.org> on Thursday March 18, 2004 @06:41PM (#8604659) Homepage
            I personally use a proprietary templating engine, but if I was to use any of the open-sourced ones, I would first look at what my requirements are.

            If you are looking for a full-fledged templating that has all the bells and whissles, I would recommend Smarty because it has a massive amount of feature and seems to be quite endorsed by official PHP developers.

            If you are looking for something a little simpler to bring more speed and less overhead to your presentation layer, I do like the approach of the Sigma templating engine (in the links posted above) as it brings only what you really need and does it very quickly.

            • Re:Power Power Power (Score:3, Insightful)

              by matt4077 ( 581118 )
              The problem with template engines is, of course, that they are either not powerful enough for what you do, or they become a new language by themselves. What good does it do, to replace a php if() { }else {} statement with some uber-xml-template-engine's ?
              None, other that everybody who needs to use your system has to learn another language.

              For a php-product of ours, we have chosen to simply use php as the template language. The codebase itself is OO and seperate from the html, but somewhere you just have
    • Separating code and content (and style) is what I use php for. If you are putting php in your html you are doing it backwards. Marked up content goes in one database table CSS goes in the other and php puts them together.

      • Re:Power Power Power (Score:4, Insightful)

        by FyRE666 ( 263011 ) * on Thursday March 18, 2004 @06:20PM (#8604457) Homepage
        If you are putting php in your html you are doing it backwards. Marked up content goes in one database table CSS goes in the other and php puts them together.
        That's possibly the most ridiculous thing I've ever read here (above -1 anyway). Why on Earth would you want to keep hammering the database for HTML markup, let alone CSS text?!! You'll find there's this thing known as a "filesystem" that does a better job at returning such content, much more quickly and more efficiently.

        If you really are using the method you suggest above, then I can only imagine you don't have a very busy site...

      • Re:Power Power Power (Score:3, Interesting)

        by sporty ( 27564 )
        Yet it does such a bad job of enforcing it. You'd think for a language who's job that acts as a conduit between your view layer and your model would at least do a good job at it.


        Or are we going to add another few thousand functions into the core language. Again.

    • Damn, you're clueless (Score:5, Interesting)

      by jbellis ( 142590 ) <jonathanNO@SPAMcarnageblender.com> on Thursday March 18, 2004 @05:36PM (#8604093) Homepage
      - for all but the most trivial sites, separating code & presentation is a Good Thing
      - PHP supports this kind of separation. google for template libraries.

    • Re:Power Power Power [where's my perl!?!] (Score:5, Insightful)

      by Telastyn ( 206146 ) on Thursday March 18, 2004 @05:38PM (#8604107)
      Huh?

      Having been a big PHP fan, let me assure you that PHP has a strong central theme like a kleptomaniac with ADD has a strong attention span.

      Having been a big PHP fan, every story about PHP releases reminds me of the page long list of vulnerabilities and issues under it's entry in netbsd's package listing.

      Having since moved to perl, I'm wondering if those death throes you're talking about are the same ones that haven't arrived on my BSD machine yet...

    • Re:Power Power Power (Score:3, Informative)

      by mcrbids ( 148650 )
      It's funny, I remember when it was a main tenet of programming that data should be separate from presentation. However, PHP has shown just how powerful integrating data and presentation can be through inlining code directly into a webpage layout.

      That tenet is still true. If this were not true there wouldn't be some 112 projects on sourceforge [freshmeat.net] with "PHP" and "template".

      I personally use PHPLib [slashdot.org] templates, something I've discussed quite publicly [devshed.com].

      Mixing logic and presentation is a no-no for effective softw

    • Separating data and presentation is more powerful in the end. That's why people make things like php.MVC [phpmvc.net].

    • Well... (Score:3, Informative)

      by nycsubway ( 79012 )
      I just think about how easy it is to create something with PHP. Not necessarily the death throws of Perl. I started with CGI and Perl, and did quite a lot of it many years ago. I've worked with ASP too; I liked the flow of it, but it was too microsoft centric. When I came to doing web programming again, PHP was what was available, and I LIKE IT! Very powerful.

      Any language that has a 4000 page Help document that is extremely easy to use and find information, is an excellent programming language.

    • Re:Power Power Power (Score:5, Insightful)

      by kevin_conaway ( 585204 ) on Thursday March 18, 2004 @05:40PM (#8604134) Homepage
      Umm, Perl is not dead or dying. It may not be used as much as it used to for CGI programming but in the world of system administrators, it is still very much alive and even growing. An admin without perl is making his or her life much worse than it could be

    • Different horses for different courses. The great thing about ever popular use of computing languages the sheer diversity and the speciality of niches.

      Don't try to compare a high level rendering and application logic language like PHP against the toolbox data manipulating kitchen sick included lanaguage of perl.

      • kitchen sick included lanaguage of perl.

        in perl it would be "kitchen sink required". if you want to include or include_once your kitchen sink, stick with perl. as a java fan i, of course, prefer my kitchen sink to be imported.

        no domestic sinks for me!

    • Re:Power Power Power (Score:5, Informative)

      by justMichael ( 606509 ) on Thursday March 18, 2004 @05:49PM (#8604203) Homepage
      Do yourself a favor and do not mix business and presentation...

      Somewhere down the line you are going to have a person working on design that doesn't understand PHP and breaks something. Then you can either spend who knows how long to figure out what is broken or throw out their work and just roll back to what's under revision control (you use revision control, right?). Either way you wasted time. Or worst case, nobody notices the logic is broken and it makes it to production.

      Go find a template engine that you like and use it. You'll be happy in the long run.

      Here's a couple to get you started.

      PHPLib [sourceforge.net]
      Smarty [php.net]

    • Re:Power Power Power (Score:3, Insightful)

      by Snoopy77 ( 229731 )
      PHP has shown just how powerful integrating data and presentation can be through inlining code directly into a webpage layout.

      A lot of people using PHP, ASP, JSP, ColdFusion are doing their best to separate data collection and manipulation with the actual presentation of the data.

      My particular favourite methodology fusebox [fusebox.org] tries to help programmers separate the model and the view. It is unbelievable how simpler web applications are to write when you do separate data and presentation.

      I may be feeding th
    • err Python and Ruby are in the same solution space as Perl where as PHP, ASP and JSP are competitors.

      Now I just finished writing a CGI/Perl app that talks to an Opto22 device using a firewire module. Does PHP have a firewire module?
    • omg perl in it's death throws? rigghhhttt...

  • Safety? (Score:3, Interesting)

    by jameson ( 54982 ) on Thursday March 18, 2004 @05:25PM (#8603982) Homepage
    Hmm... why do we always get new expressivity features and library extensions, instead of new safety features and ways for statically checking our code (such as type checking, a novel but, admittedly, completely impractical and academic invention that only freak languages use)?

    I guess because people like me prefer to complain and use other languages instead of fixing unsafe ones...
    • Type checking. Beh. Fuck that.

      My Commodore 64 with its BASIC interperter way baci in 1982 knew what I meant. My current computer is about a gabizillion times faster, and has more memory then all 64s ever built put together. So dont try to talk to me about efficency.

    • Re:Safety? (Score:3, Insightful)

      by GnuVince ( 623231 )
      Using unit testing in a test-first mode of development can make type problems go away.

    • Re:Safety? (Score:2, Informative)

      by Anonymous Coward
      Well that depends, would you include: private and protected members/methods, abstract classes, class type hints, the "final" keyword, destructors and/or exception handling as safety features?

      Since I only really use my own classes, I'm not overly concerned about hiding internal class members/methods, but I'm really looking forward to exceptions (nothing like doing a big block of queries, ALL of which have the same error checking code).

      As for type checking, yes, my partner and I (him a Perl hacker and me a

    • Re:Safety? (Score:5, Informative)

      by Wonko42 ( 29194 ) <(ryan+slashdot) (at) (wonko.com)> on Thursday March 18, 2004 @05:48PM (#8604195) Homepage
      PHP is a weakly-typed language by design, not because they haven't gotten around to implementing type checking yet. If you're feeling insecure about your code, you can always explicitly typecast [php.net] your variables or use the settype [php.net] function to calm your nerves.

      I've been using PHP extensively for years now and I can't say I've ever run into a problem with its handling of data types. Let's not forget that PHP is, after all, a scripting language.

      • Re:Safety? (Score:3, Insightful)

        by Tablizer ( 95088 )
        PHP is a weakly-typed language by design.....Let's not forget that PHP is, after all, a scripting language

        Agreed. Why does everybody want to turn PHP into Java? If you want to use Java, then use Java. Diversity is good.

    • Re:Safety? (Score:3, Informative)

      by hhnerkopfabbeisser ( 645832 )
      Type checking maybe more impractical and less useful than many people think.

      Bruce Eckel explains this quite well:
      http://mindview.net/WebLog/log-0051

  • Don't take it to school! (Score:3, Funny)

    by DanThe1Man ( 46872 ) on Thursday March 18, 2004 @05:26PM (#8603987)
    Old but still funny.

    Student Suspended Over Suspected Use of PHP [bbspot.com]

  • Much improved. (Score:3, Interesting)

    by Sheetrock ( 152993 ) on Thursday March 18, 2004 @05:27PM (#8604002) Homepage Journal
    A test run of our PHP setup on PHP5 RC1 seems to be more responsive and crisp than it was on PHP4. I've also heard the syntax is being improved in some areas, which would be quite the boon (our site looking somewhat spaghettish as it is.)

    Didn't have to jump through any hoops that weren't explicitly mentioned to get it installed, and haven't noticed any problems so far. Hopefully this is a sign that the official PHP5 is soon to arrive.

    • Did you test PHP5 or have a wine tasting?! (Score:5, Funny)

      by Anonymous Coward on Thursday March 18, 2004 @06:42PM (#8604674)
      A test run of our PHP setup on PHP5 RC1 seems to be more responsive and crisp than it was on PHP4.

      Riiight. "Crisp". Yeah, that sounds like a very analytical test run you did. Did you also notice PHP5's woody undertones and how it satisfies the spirit without weighing down the heart?

  • Time for /. to (Score:5, Funny)

    by myownkidney ( 761203 ) on Thursday March 18, 2004 @05:27PM (#8604006) Homepage
    move to PHP

    • Re:Time for /. to (Score:5, Interesting)

      by Sheetrock ( 152993 ) on Thursday March 18, 2004 @05:36PM (#8604090) Homepage Journal
      Although you might be kidding (since /. has an established base of well-tweaked high quality/high performance Perl code), not only is PHP and in particular PHP5 is an excellent choice for prototyping because of the integration between display and function, but it's probably the right choice most of the time for people who are seeking to integrate databases with web functionality without delving into high-priced solutions.

      /. is in a special situation due to the amount of traffic it receives, and the amount of effort that has gone into making Slash the powerhouse that it is has no doubt driven projects like perl_mod to increase the efficiency on the webserver side. While PHP would only improve on the appearance and capability to add user functionality, there would be issues with stability.

      • I'd say that PHP would be the selection to make if somebody were to start /. today, but when this site was started PHP wasn't a viable option and Perl ruled the day.

        I don't think it'd be possible to write the Slashcode in any new language without risking small features that work now breaking down and upsetting the few users who use that feature. Any gains from switching would be overriden by that unavoidable mess at the conversion.

    • Re:Time for /. to (Score:3, Interesting)

      by Micah ( 278 )
      For a site like Slashdot, PHP would kill performance. mod_perl caches psuedo-compiled code in the webserver. PHP has to be re-interpreted for every page hit. You can install the Zend Optimizer, but from my limited trials with Xaraya running under it I wasn't all that impressed.

      Personally, I think Slashdot needs to be re-written in C. See my journal for the complete idea.

      • Re:Time for /. to (Score:3, Informative)

        by Anonymous Coward
        You don't want Zend Optimiser (pointless) you want Turck MMCache

        turck-mmcache.sf.net

        It caches the compiled op-codes. Makes php MUCH faster. Reduced the load average on my machine from about 8 to 0.56

  • PHP in comparision to others (Score:4, Interesting)

    by frodo from middle ea ( 602941 ) on Thursday March 18, 2004 @05:29PM (#8604019) Homepage
    How does PHP comapre in terms of speed and ease of Use to other scripting languages like ASP, perl, JSP, or serverside Javascript.

    I guess a lot of PHP user base was once doing mod_perl and CGI. I personally use JSP, but often find it too cumbursome for quick hacks.

    • Not sure about speed. It seems fast enough for most stuff, but I'd do some careful benchmarking and optimization if I was writing/designing a big app.

      I've never used ASP or JSP, but PHP is much easier to pick up than Perl or JavaScript. It's very simple, and uses C/C++-like syntax without the complexity you have to learn to program effectively in C/C++.

      Unfortunately, this means that there's huge amount of PHP code that's utter crap out there, because you don't have to think before you code.
    • PHP is insanely easy to use. I think that is one of its biggest draws. I tried using JSP back in the day but it was really over the head of this artist. In terms of speed...well you're asking the wrong guy but I can't detect any difference between static pages and php pages (but my scripts are very simple). Products like vBulletin and Moveable type are very popular and seem to run at a decent speed and scale, so I think php is battle tested. Although the two web developers I know use ASP and JSP respe

    • Re:PHP in comparision to others (Score:4, Informative)

      by Charles Dart ( 731692 ) <Charles_Dart@hotmail.com> on Thursday March 18, 2004 @05:45PM (#8604176)
      PHP is very fast and easy to use. The php.net website has great documentation. With the PEAR extension database abstraction is possible making all your data functions totally portable. As for quick hacks php can be run on the command line which is very quick and very hackey. I have been using it for years in tandem with MySQL and find that it meets all my needs (except for the fact that MySQL doesn't have nested queries but that is coming in the next release and I will be a happy man!) I also know JSP and Oracle but prefer PHP/MySQL by far.

    • Here you go (Score:5, Informative)

      by jbellis ( 142590 ) <jonathanNO@SPAMcarnageblender.com> on Thursday March 18, 2004 @05:51PM (#8604226) Homepage
      Speed: they're all "fast enough." All of these scale well enough that for most sites you won't care, and none of them really scale well enough to support something like cnn.com. [Read through the archives to get a feel for the pain /. has to go through to serve its audience, for instance. And /. isn't even THAT big.] No flame; just that all these options are low/middle end.

      Ease of use:

      Classic ASP is pretty close to Perl. ASP.NET is a rather different paradigm, with a slightly steeper learning curve but more than enough added power to make it worthwhile. Unfortunately ASP.NET is a classic "leaky abstraction;" it tries to make things simple that sometimes aren't, and this will bite you.

      Perl: it's nearly impossible to maintain a substantial site in perl with multiple developers working on the code. The language works against you here. Again, /. is a case in point. There's a reason /. doesn't upgrade to the latest & greatest very often.

      JSP: takes a PHP-ish approach but Java is a statically typed language which makes using it for web apps _extremely_ verbose in comparison to the other languages here.

      Javascript: poor fit for server-side use. Nobody does anything serious with it that way.

      Verdict: They all suck to one degree or another. It's heresy on /. I know, but of these, ASP.NET is probably the best choice. If you want a toolkit/language that won't make site maintenance hell, OpenACS (tcl) or Zope (python) is probably a better bet. If you want something that will scale to absolutely huge levels (like the aforementioned CNN), J2EE is about the only game in town. (But a living hell to code for -- not recommended for smaller projects!)
      • There's a reason /. doesn't upgrade to the latest & greatest very often.

        Last I knew, it was every Wednesday night. Do you have more recent information?

      • Re:Here you go (Score:3, Insightful)

        by perrin_harkins ( 529293 )
        All of these scale well enough that for most sites you won't care, and none of them really scale well enough to support something like cnn.com.[...]If you want something that will scale to absolutely huge levels (like the aforementioned CNN), J2EE is about the only game in town.

        Yahoo uses PHP and Perl. Amazon uses Perl. TicketMaster uses Perl. These are some of the biggest sites in existence. The only truly large site using Java is eBay, and they are not using all the standard J2EE stuff. And I can't

      • Re:Here you go (Score:5, Informative)

        by flocculent ( 564644 ) on Thursday March 18, 2004 @06:46PM (#8604708)
        While I agree with the rest of your comments it's not really true to say that ASP/PHP/etc won't scale to the size of a site like cnn.com. They may not always be your best choice of language, but they do fit certain niches rather well. In general, for a website to scale well, the overall system/software design is much more important than choice of language/environment. (Though it's true that j2ee app servers give you a big headstart here)

        Whether a website will scale to cnn like levels is dependent on quite a few factors... two of the main ones that come to mind are:

        a) How much work the site has to do to build a page (think basic marketing website vs an online banking site)
        b) Sensible overall design (both code and network/hardware).

        A well built PHP site (i.e many servers load balanced, well cached page content, intelligently coded to scale from the outset) will scale to whatever you like, at least for cnn type content which is easily cached.

        I worked on one of the very few major news websites that coped with Sept11th traffic, and that website was developed using Linux/Apache/PHP/MySQL. (we only just coped mind you! ;)

        I remember reading a while back that yahoo use PHP for various bits and pieces too..

    • Re:PHP in comparision to others (Score:4, Informative)

      by justMichael ( 606509 ) on Thursday March 18, 2004 @05:57PM (#8604277) Homepage
      If you put a site together with a little planning and a properly setup cache [sourceforge.net] and then use a template engine [php.net] that supports output caching you can rival static pages depending on how often the page "needs" to hit the DB.

      This really all depends on the sites content, an average ecommerce site probably only needs to hit the database once a day, slash on the other hand could cache the front page for non-logged in users for 5 minutes, which I believe they are doing now with perl.

      As usual YMMV.

  • significant changes (Score:5, Informative)

    by berkleyidiot ( 762486 ) on Thursday March 18, 2004 @05:29PM (#8604030) Homepage
    be careful upgrading, as the semantics regarding object assignment have changed from copy to reference. i know some of my code would make use of the old copy-on-assignment semantics.

    other than that, looks like version 5 introduces some cool stuff, ala java. abstract classes, exceptions, method visibility, and interfaces to name a few. can't wait to give it a try.

    • Re:significant changes (Score:5, Insightful)

      by Carl T ( 749426 ) on Thursday March 18, 2004 @05:48PM (#8604199) Homepage
      the semantics regarding object assignment have changed from copy to reference

      Sounds to me like the migration to PHP 5 will be a long and painful one. The project I've been working on in PHP for the last couple of years sure could use some of the new features, and if what another poster said about responsiveness translates to higher speed, that's another reason to switch. Then again, looking through megs of PHP code for things that are suddenly ever so slightly broken because of subtle language changes is not exactly fun.

      For new projects, OTOH, I don't see much reason to stick with PHP 4, except the horrors of having to instruct users that they need to upgrade their PHP interpreter(s) again.

    • Re:significant changes (Score:5, Informative)

      by T3kno ( 51315 ) on Thursday March 18, 2004 @05:50PM (#8604214) Homepage
      All of the XML stuff has changed as well, I found that out while going through the Core PHP, which has been *cough* updated *cough* to cover PHP5. They forgot to mention that they were talking August 2003 PHP5, AKA PHP5 before libxml2.

      The nice thing is that it nearly completely models the functions listed in the w3c recomendation for the DOM Level 3 Core [w3.org], which are also nearly identical to the XML::LibXML module in Perl.

      So, IHMO PHP5 = Good, Core PHP 3ed = Bad!
    • be careful upgrading, as the semantics regarding object assignment have changed from copy to reference. i know some of my code would make use of the old copy-on-assignment semantics.

      Which is why it may suffer problems with a lot of hosting companies upgrading and adopting PHP5 initially. Its seems like 90% of the borrowed code and available projects out there tend to be class based (even though most small projects don't necessarily need to be done in OOP, but this isn't an argument I'm going to delve in

  • Apache 2.x safe to use yet? (Score:5, Interesting)

    by Anonymous Coward on Thursday March 18, 2004 @05:46PM (#8604185)
    I remember reading within the PHP docs about how unsafe it was to use the 2.x release branch of Apache with PHP...something to do with thread safety if I recall.

    Anybody know if PHP 5.x has overcome this limitation?
    • I've been using PHP 4.x with Apache 2.x (as a module) for over a year now, on both FreeBSD and Windows, with no problems. I haven't tried PHP 5 yet, but I imaginine it works fine too.
      • My understanding (and I don't actually use PHP, so maybe I'm out of date) is that with PHP 4.x, at least, it worked fine with the traditional fork-based Apache model, but br0ke with threads. (And for this reason, the threaded binary is installed at /usr/sbin/httpd.worker and /usr/sbin/httpd is the old-fashioned way on Red Hat's distro.)
    • The only thing I remember was a problem relating to multiple includes of PHP scripts. The PHP people pointed at Apache, Apache people pointed at PHP. Something about apache filter vs. something-or-other, blah blah blah. Suffice to say they finally got things together a while back, and I run PHP 4.3.x on a handful of production servers (some with quite high load and mostly PHP pages) without issue.

      I don't remember the exact details of the whole fiasco, but both sides racked up a black eye in my book. It

    • Re:Apache 2.x safe to use yet? (Score:5, Informative)

      by shiflett ( 151538 ) on Thursday March 18, 2004 @05:55PM (#8604267) Homepage

      You have to use the pre-fork MPM, which is the same condition you'll have when using various modules with mod_perl. Basically, PHP core is thread-safe, but you're likely to use some extensions in your own configuration, and these aren't necessarily thread-safe.

      I'm not aware of a list of "who's safe", but such a thing would be nice.

    • Apache 2.x is safe if you use the MPM (process) model, not the thread model. The problem isn't PHP, but multiple underlying libraries used by PHP. YMMV.

      Don't use PHP 5.x yet for production. Wait until it's released (at least), or a few months after the initial release.

      I have a webpage on how to build and use PHP with Apache 2.x at http://dan.drydog.com/apache2php.html [drydog.com] 4.3.4

      • Message from Rasmus [google.com] about this issue.
        • Here's what Rasmus said 6 days ago in a bug report [php.net]:

          We are not talking about just Apache2 here. We are talking about
          Apache2+an MPM+PHP+3rd Party Libs. The folks at apache.org are only
          concerned with Apache2 itself, and for serving up static files it is
          better than Apache1 in many respects. However we have to worry about a
          lot more stuff here. In fact, we couldn't care less about serving up
          static files. The main issues as I see them are:
          <p>
          1. Thread safety issues.
          - It is very difficult to track down thr

    • I remember reading within the PHP docs about how unsafe it was to use the 2.x release branch of Apache with PHP...something to do with thread safety if I recall.

      PHP is not thread safe and likely never will be. The core is thread safe, but not all the extensions are guaranteed to be thread safe due to the external libraries they use. Thread safe issues likely won't show up during testing, but will show up in production under heavy load. This is the reason Zeus recommends using FastCGI instead of ISAPI f

  • PHP5 Features (Score:4, Informative)

    by lev606 ( 763450 ) on Thursday March 18, 2004 @05:52PM (#8604234)
    An article [urlvice.com] discussing some of the new PHP5 features.

  • Php 4 vs php5 (Score:3, Interesting)

    by Billly Gates ( 198444 ) on Thursday March 18, 2004 @05:58PM (#8604284) Journal
    I wonder if I can install both so I can play with php5.

  • The upcoming release of PHP5 will create a wave of comparisons to Java. When that happens, remember that it isn't a zero sum game. The two languages work reasonably well side by side. There will come a point when the industry pundit ashclowns start repeating what you're about to read to the enterprise upper echelons. When that happens, it will get really interesting.

    PHP has two primary strengths: architecture and standards. The majority of java webspace applications were written before css and xhtml w

    • Re:PHP Advocacy: presentation layer=application sp (Score:5, Informative)

      by aled ( 228417 ) on Thursday March 18, 2004 @07:24PM (#8604961)
      You got to be kidding.
      PHP has two primary strengths: architecture and standards.
      Java is a general purpose language build from the ground up as an OOP. Java is used from embedded systems, mobile phones, desktops, webapps to world class enterprise projects. Java has a sound definition as a language and its virtual machine. Java standards are defined by the JCP [jcp.org] with formal methods for approving changes including Apache.
      AFAIK PHP is used only in webapps. OOP was added as an afterthought. PHP is a project of the Apache Software Foundation.
      Architecturally has native standard access to databases and there are drivers for every db, supports distributed transactions, has message queues, takes advantages of multiprocessors, JIT native compilers in the VM, libraries for every need. Don't know about PHP but for what I know Java has a more advanced architecture.

      The majority of java webspace applications were written before css and xhtml were mainstream.
      What apps are you talking about? The PHP changelog shows that PHP 4.0 was released in may 2000. The great mayority Java webapps are based on servlet API 2.2 or later which where release on april 2000. Please explain how Java apps are less suportive of css and xhtml than PHP. BTW, how many PHP 3.x webapps are there?

      I predict that there will be a need for css and xhtml conversions among the big java web apps and this will be readily delegated to PHP.
      If I would have a Java webapp that needs to support css and xhtml it would be ridiculous to rewrite the app in another language, when it could be easily adapted. How would I explain it to my customer? There's nothing in Java or PHP that prevents using css or xhtml or making them automatically supported.

      I don't mean that PHP isn't useful, but Java has just a broader scope.

  • Control vs. Abstraction (Score:4, Interesting)

    by Eberlin ( 570874 ) on Thursday March 18, 2004 @06:17PM (#8604437) Homepage
    Having browsed only a few ASP.NET howtos but not having had the opportunity (or misery -- since this IS slashdot) to code in it, I'm not too familiar with ASP.NET

    OTOH, I am a bit more involved in programming in PHP. I think it's fairly nice and simple enough. Haven't gotten into a lot of the OO stuff but it's still fairly powerful with the simple things I do.

    From what I've read, ASP.NET abstracts a LOT of the stuff from the programmer. Forms pretty much take care of themselves, validate on their own, and repopulate themselves for the user to correct. Among other things, this helps isolate code from content.

    From experience (which may be very limited), PHP doesn't have this feature. This allows for so much more control over what happens to your forms, but also introduces more code into the mix which could get ugly after a while.

    Thus we have control vs. abstraction -- a classic debate. Convenience and rapid development would lean towards abstraction (as anyone who coded VB may argue). Would be nice if PHP had that n00b convenience somewhere while still being great for more advanced coders.

    Ultimately, control is probably the choice for anyone who wants to get past the abstraction. Besides, in the long run, you'd probably want to write your own data validation code (or at least implement an open-source version) instead of relying on a (closed-source) language to check for you. That's simply a matter of trust.

  • Seaside (Score:5, Interesting)

    by GnuVince ( 623231 ) on Thursday March 18, 2004 @06:19PM (#8604454)
    For people who think there must be something better to write web-based applications than PHP, I invite you all to take a look at Seaside [beta4.com] by Avi Bryant, a web framework available for Squeak [squeak.org] and, I think, VisualWorks Smalltalk [cincom.com]. It uses continuations to make programming a web application basically the same as coding a desktop application. It features many, many things that PHP cannot do.

  • No need to learn (Score:5, Funny)

    by ca1v1n ( 135902 ) <snookNO@SPAMguanotronic.com> on Thursday March 18, 2004 @06:31PM (#8604573)
    For those of you who don't know PHP, just wait a version or two. It already supports VB, C, C++, Javascript and Perl style coding. Version 5 is basically Java. Expect Intercal [catb.org], Unlambda [eleves.ens.fr], and BrainF*** [muppetlabs.com] support by version 7 or 8. If you know a Turing-complete language, chances are you'll be able to use it to code PHP by the end of the decade.

  • PHP vs. Perl (Score:5, Interesting)

    by transient ( 232842 ) on Thursday March 18, 2004 @06:41PM (#8604658)
    I swear I'm not trying to start a flamewar with this, so please respond appropriately.

    What advantage does PHP have over Perl?

    At first, I rejected PHP because of its (apparent) preference for intermingling presentation and logic. As has been thoroughly discussed in another thread, separating the two is not only possible but recommended. That doesn't give PHP any points though -- it just removes a penalty.

    Both languages have a wide range of libraries/modules to choose from (although I think the score here goes to Perl). Their syntax is nearly identical. They both run on lots of different platforms. PHP is pegged as a tool for making web sites, while Perl is a general-purpose scripting language that happens to be useful for web sites too.

    So, make a business case for me. I manage a development team (I rose from the ranks so save your MBA jokes for another day) and I want to know why I should consider PHP over Perl.

    • Perl's grammar is too big (Score:5, Interesting)

      by SnatMandu ( 15204 ) on Thursday March 18, 2004 @07:37PM (#8605081) Homepage
      PHP has a smaller syntactical (is that a word?) footprint. As you said that you manage a development team, this is important. The Perl motto of "There's more than one way to do it" becomes an issue when you've got multiple developers working on the same codebase. You can write and (attempt to) enforce code style rules in your organization, which mitigates this a little bit, but it takes time to write those guidelines, get buy-in, and enforce.

      I use perl often, but I consider it a "fire and forget" language. I use it for sysAdmin type work often, when I'm doing something once, and want to write a quick script that nobody (including me) will ever lay eyes on again. For real development, where I'm trying to create a maintainable piece of software, with input from other developers, I stick to PHP.

    • Re:PHP vs. Perl (Score:4, Informative)

      by claar ( 126368 ) on Thursday March 18, 2004 @09:11PM (#8605839)
      Well, if you rose from the ranks, then you should be able to perform a simple test:
      1. Think of a task that will take about 20 minutes to program
      2. Program it in both Perl (use perldoc as another poster suggested) and PHP (use php.net/manual/en [php.net])
      3. Wait 2 weeks
      4. Attempt to add a simple feature to each script. Time yourself and compare
      5. ???
      6. Profit!

      When I go back and look at my Perl scripts I wrote a couple weeks ago, it takes me a while to get my head back into the script. With PHP, the code is always straight forward. It may be more verbose, but I understand it much more quickly than my Perl.

      Besides this, I've found PHP's documentation to be far superior to any other languages'. When I do web programming, give me PHP anyday.

      The only thing Perl has over PHP in my mind is that CPAN [cpan.org] is currently far superior to PEAR [php.net]. If you need many special libraries, you may want to consider Perl.

      </ramble>

  • Unicode (Score:4, Insightful)

    by UnConeD ( 576155 ) on Thursday March 18, 2004 @06:42PM (#8604681)
    So does PHP5 have proper Unicode support, or are we still supposed to pretend that you can treat UTF8 as ASCII and that it will 'just work'?

  • Get to know PHP5 (Score:4, Informative)

    by gabe ( 6734 ) on Thursday March 18, 2004 @07:29PM (#8605002) Homepage Journal
    If you're wanting to learn about all the wonderful new features in PHP5, then grab this book [schlossnagle.org]. It covers more advanced topics (hence the name Advanced PHP Programming) but it's an absolute must for serious PHP developers. If you're a beginner, learn PHP in general first, then grab that book.

  • Finally clause (Score:4, Interesting)

    by BlueLabel ( 639156 ) <devin_a@[ ]extreme.com ['dsl' in gap]> on Thursday March 18, 2004 @08:22PM (#8605431)
    I used to be a PHP developer, but switched to python-based content management systems due to the elegance and ease of programming in python. However, I was interested to see how PHP had progressed since the last version, and read the article linked by Slashdot.

    The main reason I initially dumped PHP was its atrocious error handling. Python and other more elegant languages use exception handling, which is much more elegant than checking return codes and setting error handlers.

    I had read earlier than PHP 5 would include exception handling, but wouldn't include the "finally" clause. For programmers that understand and use exceptions, the finally clause is _very_ useful. I try to avoid using C++ simply because it doesn't have a finally clause (and no, the object destruction mechanism is not a good substitute).

    So, I became very excited when I read the following:

    Note that there is support for "catch all" and for the "finally" clause.
    (http://www.php.net/zend-engine-2.php)

    However, I couldn't find any examples showing the "finally" clause or the "catch all" clause in use.

    So, I went grepping through CVS.

    In the changelog for PHP, it is suggested that all exceptions _must_ inherit from a base 'Exception' class, which means that catching and exception of type 'Exception' is a basic "catch all". However, I couldn't find _any_ evidence in CVS that a "finally" clause has been introduced in PHP 5.

    Has anyone here found evidence that the "finally" clause exists in PHP 5?

  • Connection pooling ? (Score:5, Insightful)

    by vlad_petric ( 94134 ) on Thursday March 18, 2004 @09:31PM (#8605984) Homepage
    All the OO features are nice, but what's really missing in PHP are some critical "enteprise" features, like true connection pooling (and no, pconnect doesn't count).

  • Stable my ass! (Score:5, Informative)

    by krumms ( 613921 ) on Thursday March 18, 2004 @09:43PM (#8606058) Journal
    I reported a showstopper bug two days ago that crashed Apache 2 hard.

    It's been fixed now, but I don't see how they can go and say "Oh, it's really really getting there now" after bugs like that have been discovered so recently.

    But PHP's development is odd to say the least. In the Betas alone, entire sections of functionality have been rewritten. From scratch. I mean, shit.

    Don't get me wrong, PHP is a great language and PHP5 is a step in the right direction but the development of PHP seems, to me at least, so hell for leather.

Slashdot Top Deals

"Pok pok pok, P'kok!" -- Superchicken

Close