Slashdot Mirror

← Back to Stories (view on slashdot.org)

PHP 5 RC 1 released

Posted by CmdrTaco on 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!"

10 of 388 comments (clear)

  1. Re:Time for /. to by Sheetrock · · Score: 5, Interesting
    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.

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  2. Damn, you're clueless by jbellis · · Score: 5, Interesting

    - for all but the most trivial sites, separating code & presentation is a Good Thing
    - PHP supports this kind of separation. google for template libraries.

  3. Apache 2.x safe to use yet? by Anonymous Coward · · Score: 5, Interesting

    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?

  4. Control vs. Abstraction by Eberlin · · Score: 4, Interesting

    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.

  5. Seaside by GnuVince · · Score: 4, Interesting

    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 by Avi Bryant, a web framework available for Squeak and, I think, VisualWorks Smalltalk. 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.

  6. PHP vs. Perl by transient · · Score: 4, Interesting
    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.

    --

    irb(main):001:0>
  7. Re:Power Power Power by loginx · · Score: 4, Interesting

    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.

  8. Perl's grammar is too big by SnatMandu · · Score: 4, Interesting

    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.

    1. Re:Perl's grammar is too big by SnatMandu · · Score: 4, Interesting

      Most of your criticisms of PHP are totally on the money.

      But come on. Once a programmer really gets into perl, only another hard-core perl person can read their scrawl. Don't get me wrong, I love perl. But it's a horrible choice for a large project with many developers.

      I've not dug into perl documentation for a while (has it been years?), but last time I checked, it was about 100 man pages. With php, if I think there's a function called split, I type http://www.php.net/split and there's the docs.

      Re: perldoc, c'mon! I get the impression you've never had to maintain code written by a hard-core perl programmer (or maybe you are one). For hobby stuff, use any language you want, but for business purposes, I don't want to have to search for developers who are so fucking specialized in perl. With PHP, I can make anybody who learned the basics fo C and make them productive in about 48 hours, working on someone else's code. With a big perl codebase, that same person is going to have to be twice as expensive if they're going to jump in head-first.

      Re: too many overlapping core functions - I don't know what you're talking about. There are a few aliases in there (ie: chop or rtrim (which actually is annoying, since chop() should work like it does in perl, IMO)), but I don't see a lot of overlap.

      I think perl is really neat, but it's overkill. I know that's the tried and true criticism, but I really think it's true. I don't want to give a group of 4-12 developers of varying cluefulness that sort of capacity to create havoc for each other.

  9. Finally clause by BlueLabel · · Score: 4, Interesting

    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?

    --
    Devin