The Standard PHP Library: Worse gets better

It’s always amusing to read the remarks of those brought to the boil by PHP, the all-time classic being a toss up between this;

PHP is a big ball of crud. The only reason it doesn’t appear to stink at first is due to the five layers of band-aid it is wrapped in.

and this

Dear Rasmus,

I want you to know that I have checked out your “open source project”, and I feel it necessary to inform you that even though you hide behind the guise of “open source”, what you produce is total crap.

Of course such remarks are often provoked by considering things like PHP’s arrays and miss the point the sorting a data structure in PHP typically looks like this;


$sql = "SELECT * FROM users ORDER BY name DESC";

It also ignores things PHP most definately does right, such as ease of deployment: “look Mom – no XML descriptors!”.

Have brought this up before with the notion that worse is better. Taking note again of what Jeff was pointing to here;

Over time, people pay more attention to software written in the New Jersey style, so it improves faster. Worse becomes better.

Looking at what Marcus Boerger has done so far with the Standard PHP Library, for me it’s cool water: worse getting better.

The big question now is what else should the SPL be doing?

Believe Marcus is open to ideas and suggestions (and of course direct help if you’re able) and input does make a difference, such as this discussion which lead to the initial implementation of Iterator::hasMore() being renamed to Iterator::valid().

Best place to get talking is the internals list.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Captain Proton

    I think the ‘negative comments’ towards PHP are more aimed at the internal code structure, instead of at the resulting product. PHP as a product may be good (open for debate of course), but the code behind it may be a hacked piece of unelegant spaghetti code (note that I am not saying that it actually is, I don’t know what the code looks like).

    One of the things I can criticise PHP on is the lack of consistency. Some examples:
    - in_array(needle, haystack) but strpos(haystack, needle)
    - no naming convention for functions: money_format or addslashes
    - PHP 5′s function parameter type hints, they work for classes but not for built-in types like strings and integers

    PHP is definitely a pragmatic language: it was built and bolted upon to support whatever features were “needed by the community”. No matter what Zend may claim, there is no clear goal: things just evolve the way they do. Whether that is a good thing or a bad thing is open for discussion.

    Consistency in a language is very important IMHO. PHP’s lack of consistency inevitably leads to bugs or at least more development time. How many times haven’t you accidentally used strpos(needle, haystack) instead of strpos(haystack, needle) and spent hours trying to find the error? Okay, maybe not hours ;), but things like that are annoying.

    I love PHP and what it does but it’s a terrible language from the point of language design. And I actually dislike PHP 5 more because of the extra inconsistency it has introduced. I believe that either a language should be dynamically typed or strongly typed, but not something in between, which is the case now with these half implemented type hints.

    That’s it for my rant :)

  • terry chay

    Most of the inconsistency in the function and method signatures comes from the underlying C functions that are implemented. In the PHP world, as you know, the resolution is PHP.net which makes searching for the correct signature very easy even to us vi guys. It’s not the best, but I don’t think anyone has ever claimed that PHP is a remotely “clean” language.

    PHP5 is dynamically typed. Type hints are entirely optional and are implemented is the same you would do a bunch of asserts() after receiving the parameters. It really is a “choose your poison” thing. This is far different than a parse/compile-time check of parameters that strong typing has! Of course, you may be wondering why bother at all. I suppose that putting the type information in the function declaration is cleaner (and nicer for PHPDoc) than putting a bunch of asserts(). *shrug*

    My beef with PHP is PEAR vs CPAN. Most of this is due to lack of namespacing. However, I’m a patient fellow. Then again, I had to wait four years for a working DOM parser in PHP…

  • http://www.sitepointforums.com Big Fat Bob

    Yo

    > Consistency in a language is very important IMHO.

    I’d have to agree with you here, also noting what you said

    > no naming convention for functions: money_format or addslashes

    I have noticed this as well, and is the lack of standards

    > PHP 5′s function parameter type hints, they work for classes but not for built-in types like strings and integers

    Prior to actually using PHP 5 I had assumed that we could hint ‘strings’ though this isn’t possible and I’m shocked at this being ignored

    All said PHP is a good language though on the point of standards, PHP I feel has yet a long way to go, if the language it’s self isn’t consistent :(

    I’m now getting to like PHP 5 though maybe in a few years PHP will adhere to one standard, thus we won’t have this

    > – in_array(needle, haystack) but strpos(haystack, needle)

  • arborint

    I think consistency is important, but with humans consistent does not always clearer. Sometimes inconsistent actually makes more sense.

    You ask “what else should the SPL be doing?” Well if “worse is better” and due to SPL “worse getting better” then I think SPL should “get worse.”

    The whole GoF/Smalltalk/Java way is about half right for PHP. It’s also half wrong.

    Which is clearer this:

    // Fetch the “aggregate structure”
    $dh = opendir(‘/home/harryf/files’);
    // Iterate over the structure
    while ( $file = readdir($dh) ) {
    // do stuff with the file here
    }

    Or this:

    < ?php
    // A magic class… (explained in a moment)
    class DirectoryReader extends DirectoryIterator {
    function __construct($path) {
    parent::__construct($path);
    }

    function current() {
    return parent::getFileName();
    }

    function valid() {
    if ( parent::valid() ) {
    if ( !parent::isFile() ) {
    parent::next();
    return $this->valid();
    }
    return TRUE;
    }
    return FALSE;
    }

    function rewind() {
    parent::rewind();
    }
    }

    // Create a directory reader for the current directory
    $Reader = new DirectoryReader(‘./’);

    // Loop through the files in the directory ?!?
    foreach ( $Reader as $Item ) {
    echo $Item.’
    ‘;
    }
    ?>

    The OOP Iterator produces a nice code snippet at the end, but OOP makes you produce the big pile of code above it. GoF stuff is intellectually satisfying, but the total code is bigger and not necessarily clearer.

    I feel strongly that PHP programmers need to come up with a different model for patterns for PHP than the Smalltalk crowd developed. There is plenty of overlap, but the differences are significant. The shared-nothing idea goes along with the fact that a PHP site is a meta application where a small separate portion of the application is executed each request. It is not a compiled-and-linked-to-a-library thing. Events, the request, and threads are all very different as well. If you squint they are similar (and maybe converging). Worst of all, you can force the development ideal of one onto the other, be they are not the same.

    I think something like SPL is an opportunity to define what the PHP Way is. That is a real challenge but we have plenty of smart programmers. Or, SPL could just be warmed-over J2EE — solving problems like looping that I just don’t hear PHP programmers complaining about. Give me a standard “PHP Way” Front/Request/Page Controller and you have my attention; give me an Iterator and I will doze off until the class bell rings.

  • Pingback: Panasonic Youth » Blog Archive » Adventures in PHP