Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
PHP Programming

PHP 5.5.0 Released 219

New submitter irventu writes "The long-awaited PHP 5.5.0 has finally been released, bringing many new features and integrating Zend's recently open-sourced OPcache. With the new Laravel PHP framework winning RoRs and CodeIgnitor converts by the thousands, Google recently announcing support for PHP in its App Engine and the current PHP renaissance is well underway. This is great news for the web's most popular scripting language." The full list of new features is available at the Change Log, and the source code is at the download page.
This discussion has been archived. No new comments can be posted.

PHP 5.5.0 Released

Comments Filter:
  • Bugs & Maintainers (Score:5, Informative)

    by TheNinjaroach ( 878876 ) on Friday June 21, 2013 @10:24AM (#44069995)
    I participated in beta release testing for 5.5 and I'm frustrated that it still has old bugs [] that cause segfaults that continue to go ignored by the maintainers. I even supplied the patch and submitted a Github pull request, but the maintainers continue to ignore it.

    It's no fun having to keep our own custom patchsets for PHP just to keep it running properly.
  • by Anonymous Coward on Friday June 21, 2013 @10:29AM (#44070041)

    The thing that bothers me most is the inconsistency in function names or argument order. When I'm using PHP, I have to constantly keep looking the functions up to make sure its doing what I expect.

  • by i_ate_god ( 899684 ) on Friday June 21, 2013 @11:01AM (#44070319)

    == and === are common in dynamically typed languages

    assert 1 == true //works
    assert 0 == false //works
    assert 1 === true // fails
    assert 0 === false // fails

  • Re:Guilty pleasures (Score:5, Informative)

    by Samantha Wright ( 1324923 ) on Friday June 21, 2013 @12:07PM (#44070865) Homepage Journal

    There are a lot of very real technical reasons why people don't like PHP. The syntax and naming of its function library is inconsistent, the type coercion is irregular, and it's inconsistent about warnings vs. errors—it tends to keep executing code even when it shouldn't, potentially leading to unwanted behaviour during development if a variable isn't set or something. Reddit has a fairly active board devoted to the various problems [] that can occur, not all of them avoidable.

    One of the most peculiar details in all of this is that PHP's original author (and, I think, but don't quote me on this, a portion of the development staff) considers himself a non-programmer; that PHP was just thrown together to simplify work. That would be okay, but it's led to a lot of security holes, bugs, and irreversible bad choices over the years, like having to use === in string parsing because false is returned by strpos() if it doesn't find anything (and false == 0). No other language requires this particular quirk.

    I don't blame you for not liking Ruby. While it's a much cleaner language, it's got some very peculiar syntactical features that make a lot of people scratch their heads—most notably, there are circumstances under which return doesn't work normally [], which can be very frustrating. However, there are some very creative uses of familiar syntax that, for example, make strings really easy to work with; haystack['needle'] = 'thread' is the same as $haystack = str_replace('needle', 'thread', $haystack) in PHP. I haven't used it personally, but I think the major reason Ruby projects get abandoned so much is because the people writing code in it are not experienced programmers.

    Running down the list a little and hopping over JVM stuff, the other decent web languages you may want to consider are Perl and Python. Both have extremely well-developed libraries and are good with strings, so it's mostly just a question of picking "esoteric and terse" vs. "newbie-friendly and easily maintained." Decent JVM languages include JWT, Scala, and Clojure (with noir []; check out that sexy beast), although JWT is probably overkill for anything smaller than Gmail.

  • by garyebickford ( 222422 ) <gar37bic@gma i l .com> on Friday June 21, 2013 @01:09PM (#44071517)

    Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.

    Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)

    This is my most recent 'fave' quote from perlsyn - on 'when', which is part of Perl's attempt to rethink (or something) the switch/case pattern []:

    Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

    Pathologically Eclectic Rubbish Lister [] indeed!

    Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.

    A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".

    But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.

Due to lack of disk space, this fortune database has been discontinued.