Slashdot Mirror


PHP 5 RC 1 released

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

15 of 388 comments (clear)

  1. Safety? by jameson · · Score: 3, Interesting

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

  2. Much improved. by Sheetrock · · Score: 3, Interesting
    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.

    --

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




  3. PHP in comparision to others by frodo+from+middle+ea · · Score: 3, Interesting
    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.

    --
    for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
  4. Re:Power Power Power by Charles+Dart · · Score: 3, Interesting

    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.

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




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

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

  8. The "good design" police... have fun with it! by turnstyle · · Score: 3, Interesting
    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.

    --
    Here's what I do: Bitty Browser & Andromeda
  9. 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.

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

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

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

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